Hallo Besucher, der Thread wurde 3,5k mal aufgerufen und enthält 17 Antworten

letzter Beitrag von mega65 am

Vic 20 core?

    What does it take to be a VHDL programmer?

    I don't know much about it, but I used to do some 6502/6510 programming in assembly and machine language in the 1980s when I was a teenager.

    I'm from the USA and I'd like to help but I don't know how.

    I know the Commodore 128 used an 8510 CPU and simulated the Commodore 64 mode sprites using software instead of a VIC chip. I think they did that to save money.

    I think the goal should be to get a Mega65 with C64 and C65 mode working and earn money to pay more VHDL programmers to emulate the other 8-bit systems or even a Z80 CP/M-80 mode.

    Ok I found more info here:
    http://forum.6502.org/viewtopic.php?f=10&t=3690

    https://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html

    http://esd.cs.ucr.edu/labs/tutorial/

    https://www.nandland.com/vhdl/…o-vhdl-for-beginners.html

    I was in UM Rolla now Science and Technology, but in 1986-1987 taking computer science classes and pondering getting into electrical engineering. I wanted to go there for computer engineering but they didn't offer it anymore. I was fascinated by the Commodore Amiga 1000 and wanted to design my own computers to run the software and operating systems from other computers. I wanted like an Intel or Mortola for the main CPU and then use 6502, 6809, Z80, etc for the co-processors that ran the old 8-bit software on them.

    I now see that VHDL is designing the new chips that run the older software and OS/ROM, but seems to be hard to do because there are physical limitations such as MHz can't be above 50 or 100 in some cases.

    VHDL is an example of a HDL, that is "Hardware Description Language" (the other well-known alternative can be Verilog). It cannot be easily compared with a "programming languages" like C, C++, Java, etc etc. About the "pay more VHDL programmers to emulate the other 8-bit systems": This is not emulation! Emulation is done if you write some (for example in C) software run on a computer (like on a PC) to emulate something. VHDL implementation is different, it's a hardware level implementation of what it describes as a hardware, and not an emulation (ie the emulator software). Basically this makes it hard to find many VHDL guys: it's not so easy to learn and understand with "only" programming language backgrounds (like for a C or C++ coder), since they're totally different in the very nature. I can say this with my experience, I also try to learn VHDL, really it's not so easy as the first glance, even if you have decades of programming language experiences otherwise (but surely, it can be the case, that it's just more hard for me, than for others, who knows).

    Sort of like how a PLC uses RLL that is based on electronics rather than assembly language or C++ that is based on logic instead?

    If the Mega65 does bank switching, can you set up virtual 64K areas in the RAM with the 32 Bit register that jumps to it via bank switching? You could make one 64K area for C64, another for VIC-20, and a third for C16 and maybe a fourth for GEOS (I think if GEOS is added to a ROM and then loaded into memory from the ROM which can be reprogrammed as a EEPROM it could load the machine faster.)

    A major selling point for this machine would be that you don't have to wait long for it to boot and load programs like some modern PCs do. It also does not take that long to be shut down either. Look at how long MacOS or Windows takes. Sometimes simple and smaller memory footprint is better.

    :: @Norman King added on 26 Oct ’17 · 05:18

    Here is a VIC-20 and C64 memory map comparison:

    http://www.commodore.ca/manual…vic-20_c64_memory_map.pdf

    Here is a C16/Plus4 memory map:

    http://www.zimmers.net/anonftp/pub/cbm/maps/C16.MemoryMap

    I do think the priority is getting the C65/C64 software working first.

    Can all three machines use the GS4510 CPU and VIC-VI chip in Vic-II and Vic-III modes?

    @Norman King: I doubt that any other machine implementation (let's call it as "core") can use GS/Mega components. They would be totally separated cores. Re-using any Mega components would be hard, since it's created for that environment which is quite different in needs for other machines to be implemented. Remember, it's not a programming language (I mean VHDL) it's a bit tricky to re-use components in another project, unless it's developed that way from the very beginning. There are projects like that, for example T6502 is a BSD licensed 6502 core and nothing more (more like buying a 40 pin DIP 6502, also here you "see" the input/output signals, you must "connect" in VHDL into your project as it was a real DIP chip package with pins ... well, more or less at least), and it's not hard to use in any project needs a 6502 CPU implementation in an FPGA. Also, VIC-III is VIC-II backward compatible (we can say, though there are differences still), and VIC-IV is VIC-III compatible. But VIC-I (in VIC-20) is kinda different topic, VIC-II is not backward compatible with VIC-I. So a new VIC-I core must be developed as well. C16/Plus4 uses the chip called "TED", again, it's not so much common with VIC-II (this VIC-III and VIC-IV). Memory map differences are really the smallest problem in these case :)

    But now, I'm interested, if I can create anything which at least able to drop me into VIC-20 BASIC prompt, I guess it's a nice project for a VHDL beginner, like me ... well, guys, at least I could blink a LED already ;-P Sounds scary enough, indeed :)

    If the SID can be emulated in software then so can a VIC-I or Ted chip.

    I am looking at used Commodore systems in eBay, it seems the chips and keyboards are worth more than an As-Is used Commodore system. Getting a C64 Reloaded Motherboard and adding in the chips from an Old 64 seems to cost more than a Mega65 system.

    So the used chips are expensive, someone could make a VIC65 system using older chips and a GO20 mode to go into the VIC-20 mode, but you would have to do a feasibility study to see if it is worth it. The VIC-20 had a different cart slot than C64 as well, etc.

    My advice is to support the Mega65 project and see how well it does before making the C16 or VIC-20 versions. The majority of people want a C64/C65/Mega65 system because it has a large collection of software behind it. C16 and VIC-20 never had GEOS either that I know of.

    What do you mean about software emulation? This is hardware implemented inside an FPGA, not software and not emulation. I am confused now what you mean. Do you want to run a software on top of Mega65 core to emulate TED or VIC-I? It would be kinda slow still. And if someone really does a VIC-20 (or C16/Plus4) core, it probably would be a stand alone core so user can load M65 core or those, but how would you plan to "mix" them as you suggested? It wouldn't be so easy, and would result is a way complex hardware/VHDL design. And even that maybe the FPGA is not enough large anyway for a "super hardware clone" to capable of working as these quite large number of computers anyway. Other similar projects (FPGA arcade and such) also uses the theorem to have different cores, and not to "mix" those together, it's extremely hard, totally different timing, design etc etc.

    At this point, I'll have to concede the debate to you LGB.

    It would be better to make a different FPGA system to run VIC-20 software.

    It was just a dream I shared with people to emulate the Commodore 8-bit Home Computers on one machine, but it seems impossible. The C64 was the best seller, the VIC-20 and C16 didn't do as well as the C64.

    VIC20 Core would be nice although I think a 264 Core would be more appreciated.
    First the user base is greater and second: many TEDs and CPUs of that series are quickly dying recently (due to bad manufacturing/changing production methods?).
    Anyway: the MEGA65 is first of all a c65 'XT' (eXtendet Technology [and in 30 years from now someone would introduce the MEGA64 AT Advanced Technology :-)]) with hopefully 100% accurate c64 modus.
    But it might be wise to already reserve extensions for the 'GO' command, so it could handle GO 20 (VIC) and GO 16 (264) ;-)