C64 updated to FPGA64 v0.27

[tcdev]

The C64 project has been updated to Peter's last public source release (v0.27).

This fixes the graphics problems in v0.22 that shows glitches in most games and renders some games unplayable.

I have tested the external 1541 drive on the DE2 project.
I have also tested the SID.

The DE1 build should also work with external 1541 drive.

Note that you need a custom add-on board, which I am considering producing in small quantities for this and other projects for the DE1/DE2.

[vanfanel]

I would be very interested in a custom board for DE1 with joystick ports (I made mine at last but I'd like a better-soldered one) and 1541 port.

Whould the 1541 ULTIMATE work with souch an add-on? I'm NOT fighting with old, aging disk drives..

[tcdev]

I don't see why it wouldn't work, as it should connect to any device that works on the serial bus.

I really should get one myself and give it a go! :D

[vanfanel]

I would be glad to buy an interface to connect a 1541 ULTIMATE to the DE1. Are you seriously planning to sell those?

[tcdev]

I would be glad to buy an interface to connect a 1541 ULTIMATE to the DE1. Are you seriously planning to sell those?I'd like to, yes. However, today I was writing down my requirements and I got a little "ambitious". :D

I am now seriously considering adding a little ARM micro with USB host controller - for 2 reasons:

1. So you can add a USB gamepad/controller to use on the DE1/DE2.
2. To provide FAT filesystem support via a SPI connection - either to the original SD/MMC slot on the DE1/DE2, or a 2nd slot on the I/O board.

The problem with game controllers is that you can't (generally) buy the connectors. So most options will simply be thru-hole solder pads on the board for the user to attach a hacked extension cord or controller. One notable exception is the NES, for which connectors _are_ available.

However, the I/O board will provide the correct signal conditioning etc for each controller option. I plan on supporting NES, SNES, N64, NGC, DC and PSX and maybe atari & megadrive joysticks. And possibly legacy analogue pot sticks like Apple II/Coco, and maybe Wico trackball (I have one somewhere). There will a 2nd (and maybe 3rd) PS/2 connector as well.

This should all fit on a single GPIO connector on the DE1 or DE2, with some options requiring the user to choose whether they want support for, say, 2xNES or 2xSNES or 1xNES+1xSNES etc...

That should satisfy most requirements from Space Invaders thru to Minimig & Zet! :cool:

EDIT: Oh yeah, and C64 IEC bus as well of course...

[Talus]

Personally, I would suggest you hold off buying an 1541 Ultimate until there's a new hardware revision and/or firmware out. There are critical bugs in the current firmware (such as freezing, and consequently swapping disks, being unreliable).

Both are supposedly on the way, alas without any timeframe given. It does bother me a bit that the developer focuses on a hardware redesign, when there are known bugs in the firmware, but that's how it is with these small one-man hardware projects, I guess...

[tcdev]

Personally, I would suggest you hold off buying an 1541 Ultimate until there's a new hardware revision and/or firmware out. There are critical bugs in the current firmware (such as freezing, and consequently swapping disks, being unreliable).

Both are supposedly on the way, alas without any timeframe given. It does bother me a bit that the developer focuses on a hardware redesign, when there are known bugs in the firmware, but that's how it is with these small one-man hardware projects, I guess...

Thanks for the heads-up. I sort-of gathered as much looking at the site and forums yesterday. Gideon has posted that he's having a break - problem is there's NO date on the news posting, so I can't tell if it was 6 months ago or yesterday! :confused:

I also read that there's better hardware out there...

In any case, anything running off the IEC bus should in theory be compatible. We've had a real 1541 drive connected to the DE1/DE2 emulating a C64, and had a real C64 connected to the DE1/DE2 emulating a 1541, for example.

[Talus]

Better hardware? I think the hardware is very capable; SRAM, DRAM, 250K gate FPGA, flash, ethernet, SD card. There are even pads for a JTAG connector, I think. The FPGA could be bigger, but that's just evolution :)

I'm still hoping one day Gideon will open source the hardware implemention, or at the very least provide info on pinouts/constraints to enable 3rd party development.

The software part is already available for download (SVN), running on a softcore 6502 inside the FPGA, IIRC.

If FPGA64 supports IEC, then I don't see why the 1541U shouldn't work with it.

[tcdev]

I'm still hoping one day Gideon will open source the hardware implemention, or at the very least provide info on pinouts/constraints to enable 3rd party development.
I'd be interested to know how the FAT filesystem is supported - if that's how it works. Of course PACE SVN contains a 1541 emulation - there's just no FAT support. In theory, a 2nd soft core processor would be able to run software to either read images from a FAT filesystem, or read raw disk images (G64) off the SD card. I had some success in PACE with the latter using a NIOS...

People with a DE2 may not require a 1541 Ultimate if I add the ARM micro to the I/O board... I could read FAT into an on-chip 1541 emulation! :cool:

[Talus]

In the 1541 emulation, FAT is only used as a means of mounting a D64, I think. Mounting an entire FAT volume as a virtual 1541 would work, but break compatibility with 90% of all multiload games/demos, since they use fast loaders and specific disk layouts.

I'm not sure if this is what you meant, however.

[tcdev]

In the 1541 emulation, FAT is only used as a means of mounting a D64, I think. Mounting an entire FAT volume as a virtual 1541 would work, but break compatibility with 90% of all multiload games/demos, since they use fast loaders and specific disk layouts.

I'm not sure if this is what you meant, however.

What I meant was - how is the FAT reading implemented?

Without an external micro on the board, I would guess that a softcore processor is doing the work, much like the design in Minimig for example. It might be possible - with a clever design - to have the 1541's 6502 "context-switch" to do the read/write to/from a RAM buffer, but it'd be tricky to get right without breaking timing between the C64 and 1541. Much easier - though a lot more resource hungry - to add another soft core processor.

It is also necessary, of course, to decode the D64 header and also wrap raw track data around each of the sectors in the D64 file - something else much more suited to a processor than HDL.

I guess what I'm saying is that I would be very interested to see the hardware design as well! ;)

EDIT: DOH! I just realised the software design is open source - and 6502-based! :o

[tcdev]

Just had a quick look at the software that Gideon open-sourced.

Looks like a fair amount of work has gone into the design. There's quite a bit of code there, in both C and assembler, which I'm assuming runs on a 2nd 6502 in the FPGA.

There's some documentation about the memory maps, and to be fair they would require more than a quick perusal to really sink in, but my initial impression is that it would require some more "overview"-type documentation in order to develop anything radically different for that hardware. For example, there's very little (if any) documentation on the I/O available to the 6502, other than memory maps.

Other than that, nothing too surprising. Uses the freely-available FatFS code to read a D64 image into external RAM and constructs raw track data around each sector - just like MESS! :p Various ROM images for 1541 and cartidges are stored in external flash.

Interesting...:cool:

[Talus]

EDIT: DOH! I just realised the software design is open source - and 6502-based! :o

I thought that was what I said... :)

Just had a quick look at the software that Gideon open-sourced.

Looks like a fair amount of work has gone into the design. There's quite a bit of code there, in both C and assembler, which I'm assuming runs on a 2nd 6502 in the FPGA.


Some of the code is bound to run on the C64's 6510 too. Things like disk image selection, the freezer-menu, or any user-interaction, really.

There must be at least two 6502 cores on the FPGA; the 1541 needs one for executing its ROM image and there needs to be one for general use/house keeping. It could be a multiplexed core, to cut down on the size. It appears to be of his own devising.

[tcdev]

I thought that was what I said... :)
Yes, you did - hence the DOH! :)

Some of the code is bound to run on the C64's 6510 too. Things like disk image selection, the freezer-menu, or any user-interaction, really.
Hmmm, fair enough, didn't realise that.

There must be at least two 6502 cores on the FPGA; the 1541 needs one for executing its ROM image and there needs to be one for general use/house keeping. It could be a multiplexed core, to cut down on the size. It appears to be of his own devising.
Agreed. I'd guess there's two though - I've yet to see a multiplexed core released, although MikeJ mentioned a multiplexed Z80 core a few years ago for Xevious/Galaga someone was supposedly working on... wouldn't have thought it was too difficult to do, but as I said, I've yet to see one...

[Talus]

Hmmm, fair enough, didn't realise that.
I'm pretty sure the 1541U uses the same approach taken by utility cartridges such as the Action Replay or Expert Cartridge back in the 80's. When you hit the "freeze" button, the cartridge maps its own memory into the C64's address space and sends an NMI to the CPU. The CPU will write the state of the registers to the newly mapped-in memory, not overwriting anything. Afterwards, the cartridge can freely run its own code without disturbing the state of whatever was running on the C64. When you're done, the cartridge can restore the registers from the NMI and map itself out and the original program can be resumed. That's the idea in broad terms anyway. I could imagine there's some synchronization with the VIC chip involved as well :)

This approach is surprisingly reliable and will freeze/resume most games/demos, unless they're specifically coded to avoid it.

Agreed. I'd guess there's two though - I've yet to see a multiplexed core released, although MikeJ mentioned a multiplexed Z80 core a few years ago for Xevious/Galaga someone was supposedly working on... wouldn't have thought it was too difficult to do, but as I said, I've yet to see one...

How hard can it be... ;)

[Talus]

Not quite as simple as I made it sound:

http://codebase64.org/lib/exe/fetch.php?media=base:safely_freezing_the_c64.pdf


Interesting reading, if you're into C64 hardware :)

[nunya_bizness]

I personally am wondering if he did something in VHDL close to what was done with the vector06c floppy implementation using a 6502,of course using his 65GZ02 core (which I have yet to see source).

[Talus]

Not knowing the vector06c, I can't say :)

As far as I know, the IEC bus used on the Commodore is very timing sensitive, especially with custom fastloaders which rely on cycle-accurate code executing on both the C64 and the 1541 floppy drive (which had its own 6502 and was a computer all by itself). VHDL would definitely be required to implement the low-level IEC bus protocol, and obviously you'd need a 6502 just to emulate the procsessor in the 1541.

[tcdev]

As far as I know, the IEC bus used on the Commodore is very timing sensitive, especially with custom fastloaders which rely on cycle-accurate code executing on both the C64 and the 1541 floppy drive (which had its own 6502 and was a computer all by itself). VHDL would definitely be required to implement the low-level IEC bus protocol, and obviously you'd need a 6502 just to emulate the procsessor in the 1541.
The IEC bus is driven directly from the 6510/6502 (via PIAs) in the C64/1541 respectively. The "low-level protocol" is all done in software, hence there's nothing to do in HDL except wire the bus between the PIAs.

The critical timing, therefire, would involve keeping the 6510/6502 cycle-accurate with a responsive PIA/IEC wire implementation.

[Talus]

Ah, I see. But I suppose that the drive-mechanism part of the 1541 will also need to be emulated and provide realistic latencies for seeks, transfer rates, etc. and this could be implemented in HDL, if only for the fact that the FPGA provides much more fine grained timing control than a CPU.

[tcdev]

Ah, I see. But I suppose that the drive-mechanism part of the 1541 will also need to be emulated and provide realistic latencies for seeks, transfer rates, etc. and this could be implemented in HDL, if only for the fact that the FPGA provides much more fine grained timing control than a CPU.
I don't think the timing for the mechanism is particularly critical. With a real disk, you have a motor that must spin up, and a spinning media whose angle is completely unknown, so you need a reasonable amount of lee-way when starting to read from the disk.

What is perhaps most critical - at least at one extreme - is the rate at which data becomes available once a track has started to be read. That would be reasonably static, given an accurate rate of revolution of the drive motor. As long as you can read from emulated media fast enough, it should be sufficient. I've certainly had success emulating media and feeding data into a FIFO that delivers data to the 1541 emulation in the FPGA.

Once you start reading data from the surface of a track/sector, there's not a lot else you can do and you certainly can't speed it up or slow it down in any way via software. Of course, custom formats can improve performance by reducing unnecessary disk revolutions by arranging sectors in a certain order, for example.

The bottleneck in the C64/151 scheme is the serial transfer speed - I'm pretty sure fastloaders have found a way to squeeze more bandwidth out of that by cycle-counting during custom transfer protocols and timing IEC signalling at the limits of practical operation at the expense of robustness.