C64 Tape Port

[trekiej]

Has anyone here used a 64hdd ( http://www.64hdd.com )before?
If so, how did you like it?

[Linde]

How about a tape port to tape port transfer? Has this been done?

Not as far as I know. There is already both a serial port and a parallel port better suited for this kind of task. But it would be quite a neat hack, I agree

The cart port I guess would go at a speed of 8/8 * 1 mhz = 1 MB/sec. theoretical.

Yep, I think 16k (?) on the cartridge port can be mapped as ROM/RAM so you can access it at as such. There's also DMA, where the cartridge can grab the bus and move data at 1 byte per cycle. That's the only way to support that kind of transfer rate, and it's used by REU cartridges to transfer blocks of data from and to mapped memory.

I did see a video of the introduction to "Dallas" played from a REU.

[trekiej]

Here is an interesting link.
http://en.wikipedia.org/wiki/Commodore_64_peripherals

[Zac67]

@Linde

Are you sure the REUs DMA into local memory?? I'd rather guess that they overlay onboard memory with the page you select.

I once built a DMA interface to the Amiga where the 64's RAM was accessible through a 64K page on the Amiga - amazingly simple to build.
It worked somewhat, with lots of garbage coming along and writing to the 64 invariable crashed it (very likely memory corruption from the garbage). Guess I didn't really handle bus synchronisation correctly but the VIC does some funny stuff there...

[trekiej]

If I remember correctly there is a location in ram that the REU constantly look at to check for commands, data, etc.

[LoadWB]

Not as far as I know. There is already both a serial port and a parallel port better suited for this kind of task. But it would be quite a neat hack, I agree

I tried one day a long time ago, but it didn't work as well as on the TI-99/4A, though that required a pre-amp.

Yep, I think 16k (?) on the cartridge port can be mapped as ROM/RAM so you can access it at as such. There's also DMA, where the cartridge can grab the bus and move data at 1 byte per cycle. That's the only way to support that kind of transfer rate, and it's used by REU cartridges to transfer blocks of data from and to mapped memory.

With all address and data lines available at the cartridge port, it's possible to map the entire memory space to the port, but there are some requirements.  Off the top of my head, I cannot remember all the restrictions, but I do recall some issues with the on-board address decoding done by the PLA, the data and direction port of the 6510 ($00 and $01,) and what-not.

The REU can DMA directly into and out of C64/128 memory, though I'm not as familiar with the C128 banking as I probably should have become.  The REU has three commands: FETCH, SAVE(?), and SWAP.  I haven't touched my REU code in so damned long (you guys really kill me when you dredge this stuff up, makes me want to dive right back into it,) but ISTR you put the REU bank, C64 bank, possibly the number of bytes to transfer, and then the command into registers mapped into I/O space at $DE00 or $DF00.

Fun stuff. REALLY fun stuff.

[trekiej]

Sorry to dredge
Here is a compilation of Load Star.
http://www.ramblehouse.com/loadstarcompleat.htm

[Zac67]

I'm still not really sure whether there's actually a DMA going on - it'd just be a waste of time since all of the REU's data is already in memory (not necessarily main memory though)...

The expansion port can override the PLA's memory decoder, so essentially it can - whenever it detects an access to one of its locations - switch off all onboard devices and put whatever data on the bus. To the CPU the data seems to be read from location $E100 when in reality it comes from $08E100 from the REU memory (just an example, I've got no idea which addresses are used).

So, actually DMAing (=copying) the data for a 256 byte page (or whatever) into main memory takes 256 cycles. That's a huge waste of time since mapping the data into the CPU's address space so it looks like main memory essentially takes no time for there's no data actually moved.

I can imagine that someone really called that "DMA" to point out the speed, but it should be much faster. Additionally, DMA requires a lot more logic than simple mapping. IMHO it doesn't make any sense.

[LoadWB]

I'm still not really sure whether there's actually a DMA going on - it'd just be a waste of time since all of the REU's data is already in memory (not necessarily main memory though)...

The expansion port can override the PLA's memory decoder, so essentially it can - whenever it detects an access to one of its locations - switch off all onboard devices and put whatever data on the bus. To the CPU the data seems to be read from location $E100 when in reality it comes from $08E100 from the REU memory (just an example, I've got no idea which addresses are used).

So, actually DMAing (=copying) the data for a 256 byte page (or whatever) into main memory takes 256 cycles. That's a huge waste of time since mapping the data into the CPU's address space so it looks like main memory essentially takes no time for there's no data actually moved.

I can imagine that someone really called that "DMA" to point out the speed, but it should be much faster. Additionally, DMA requires a lot more logic than simple mapping. IMHO it doesn't make any sense.

"6) _Transfer Speed_ During DMA the CPU is halted and the memory access cycles normally available for the CPU are now used to access one byte each. So with screen and sprites switched off in every clock cycle (985248 per second on PAL machines) a byte is transferred. If screen is on or sprites are enabled transfer is a bit slower, as the VIC exclusively accesses RAM sometimes. An exact description of those "missing cycles" can be found in Commodore Hacking Issue 3. Comparing memory areas is as fast as transfers. (Comparison is stopped once the first difference is found.) Swapping memory is only half as fast, as for every bytes two C64 memory accesses (read & write) are necessary."
http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/programming.reu

Er, anyway, you're right, a memory-mapped solution *would* be faster, but that's not how the REU works.

[cgutjahr]

I'm still not really sure whether there's actually a DMA going on - it'd just be a waste of time since all of the REU's data is already in memory (not necessarily main memory though)...

It is in fact DMA, you are programming the controller in the REU to transfer from/to REU and it can also swap or compare C64 and REU memory areas. "Memory areas" meaning whatever start address and number of bytes (up to 64k) you desire, that's one advantage of this approach.

You can also use the DMA controller to move large amounts of data inside the main memory (copy to REU, copy back from REU at different position) much faster than the actual CPU running a copy loop could. GEOS actually uses this approach to speed up the display routines, and there's at least one scene demo out there utilising this.

[Linde]

@Linde

Are you sure the REUs DMA into local memory?? I'd rather guess that they overlay onboard memory with the page you select.

I once built a DMA interface to the Amiga where the 64's RAM was accessible through a 64K page on the Amiga - amazingly simple to build.
It worked somewhat, with lots of garbage coming along and writing to the 64 invariable crashed it (very likely memory corruption from the garbage). Guess I didn't really handle bus synchronisation correctly but the VIC does some funny stuff there...

Yes, I'm certain about it. I did some REU programming quite recently, so it's still fresh in memory. The only thing that is mapped into addressable memory are the REU registers that are used to control transfer and set the internal REU page. DMA is done at 1 byte per cycle, so you can effectively use the thing as a crude blitter, and you can do automatic pointer increments (at least on the REU side, not sure about the C64 RAM pointer), so you can do things like register streaming really quickly. The fact that you don't have the REU RAM mapped has these benefits besides being able to use it with pretty much any other cartridge if you have a cartridge expander.

[Linde]

ments/chipdata/programming.reu[/url]Er, anyway, you're right, a memory-mapped solution *would* be faster, but that's not how the REU works.

Yeah, it would be faster, but only for some specific use cases. DMA transfer still has the obvious benefit of being able to move data to and from arbitrary chunks of memory reasonably quickly, so for some use cases it is the faster option, and either way it's the more flexible option. I figured you could do 5 minutes of 50 fps monochrome PETSCII video with a 16 mbyte REU (like the one in the 1541U cartridge). I've set up a transfer interface with an Arduino, so that I can transfer the data from a PC pretty quickly, and also issue REU commands to upload it to the REU.

[RobertB]

Here is a compilation of Load Star...

Be aware that Fender Tucker's compilation only includes the Loadstars he worked on up to issue 199.  Dave Moorman took over publication of Loadstar issues 200 to 249 with an unofficial 250 release back in June, 2010.  None of issues 200 to 250 have been compiled into a collection.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
July 27-28 Commodore Vegas Expo v9 -
http://www.portcommodore.com/commvex

[LoadWB]

Yeah, it would be faster, but only for some specific use cases. DMA transfer still has the obvious benefit of being able to move data to and from arbitrary chunks of memory reasonably quickly, so for some use cases it is the faster option, and either way it's the more flexible option. I figured you could do 5 minutes of 50 fps monochrome PETSCII video with a 16 mbyte REU (like the one in the 1541U cartridge). I've set up a transfer interface with an Arduino, so that I can transfer the data from a PC pretty quickly, and also issue REU commands to upload it to the REU.

True.  I was thinking more for direct access.  Using an REU in the C64 like the 128's MMU bank switching would be great.  Sure, you couldn't access all memory at once due to the limited 64k address space, I/O devices, and what-not, but it would be faster.

Given our purpose of moving data around memory, the REU's DMA is far superior to anything CPU-based.  I've seen some POC which move data from the REU to video memory, making animations stupid fast.  You could take a full snapshot of 64 memory as a fast loading image of a running program or game.  Neat stuff.

[Zac67]

Thanks for clearing this up! I still have problems imagining a case when this DMA scheme is of any real advantage compared to bank switching but my imagination may just fail me.

I'd have designed it with bank switching, using several (maybe 4) programmable windows of maybe 256, 4K or 16K in size and any location on a 256 byte boundary. That way you could flip the required memory in the matter of a single clock - even changing memory in time for the VIC to pick up. It wouldn't only be faster and save precious bandwidth but also not require a transfer buffer (you get back the mainboard memory when you switch the window off) which does have a point on a 64K system.

Anyway, DMA has some advantage if you want to look at the memory as secondary storage (while the bank-switching would treat is as primary). To make a real point, the cartridge would require a file system and battery backup however.

[trekiej]

Crude Blittler sounds cool.
http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/programming.reu
A cartridge like fire fox for NES which contained a processor is neat thougth.
@ RobertB: Thanks did  not now that.