Amiga.org
Operating System Specific Discussions => Other Operating Systems => Topic started by: trekiej on March 12, 2013, 02:28:14 AM
-
Fast do you think the C64 Cassette Port runs?
1\8 * 1 or 2 MHZ = 128k or 256 k.
Was there ever a fast cassette for the C64?
-
Fast do you think the C64 Cassette Port runs?
A C64 runs at 1 MHz. The cassette port transfers at 50 bytes per second.
Was there ever a fast cassette for the C64?
If you are talking about fast loaders/savers for cassettes on the C64, yes.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
-
To be precise, the cassette port samples at 1000000 (more or less) ticks per second, allowing a theoretical throughput of (1000000/8) bytes/s = 125KB/s.
That's a completely theoretical limit, of course - no loader gets even close (the ROM loader being 50 bytes/s) but in theory if you could sample reliably that to work out if the flux had changed or not you could get that rate. If you wrote a routine to check for changes in flux that often and connected it to a digital input, you could get that rate if your tape routine consisted of one instruction - which of course it won't.
In reality, I believe the fastest loaders were probably running at about 300 B/s (2400 baud) but that's just a guess from what I've observed.
-
If my maths is right - doesnt that mean it should be possible to record an 8bit 22khz sample via the tape port - with some headroom?
-
If my maths is right - doesnt that mean it should be possible to record an 8bit 22khz sample via the tape port - with some headroom?
That is kind of what I am thinking.
-
In reality, I believe the fastest loaders were probably running at about 300 B/s (2400 baud) but that's just a guess from what I've observed.
You run into problems with frequency response before you run out of CPU speed. There were fast loaders that had to be slowed down because the duplicators couldn't cope with them.
You have to take into account what the tape is made of & the analogue to digital conversion in the C2N.
Writing a 1 bit audio sample to the tape at full speed would be kinda interesting. However I don't think the bit that you write gets put straight onto the tape, I believe there is some additional circuit in the C2N. IIRC the zero's and one's are modulated on the tape somehow, not just stored as is.
-
Back in that days I remember having tried a program published on a book that samples audio tapes played by the tape port, the sound was not that good but it was funny and was running so it was possible..
-
I've often wondered if sampling could also be achieved via the joystick port (isnt there an A2D converter for the pots in the paddles ? )
might not be too high resolution though.
N
-
The cassette port transfers at 50 bytes per second.
That fast?! It seemed slower. ;)
-
If my maths is right - doesnt that mean it should be possible to record an 8bit 22khz sample via the tape port - with some headroom?
Not a chance, I'm afraid. The tape port is digital, not analogue, and is serial. You can write a '1' to it, and you can write a '0' to it, but that's all.
When you read the tape on a C64, the downward transition triggers an interrupt via the VIA (if you see what I mean). You don't have full control of the wave, just transitions from +ve to -ve.
Sorry. :)
@PSXPhill
That's basically what I was trying to get across, yes. :)
-
That fast?! It seemed slower. ;)
You're confusing that with the 1541 drives...
-
Not a chance, I'm afraid. The tape port is digital, not analogue, and is serial. You can write a '1' to it, and you can write a '0' to it, but that's all.
When you read the tape on a C64, the downward transition triggers an interrupt via the VIA (if you see what I mean). You don't have full control of the wave, just transitions from +ve to -ve.
Sorry. :)
@PSXPhill
That's basically what I was trying to get across, yes. :)
Not necessarily. COMPUTE! Magazine had an ML program for the Apple which read the cassette in port in single-bit precision. As well, we played with a similar program on the TI-99/4A which did essentially the same thing.
It was scratchy and sounded pretty horrible, but it did work. In fact, one year I went away for school I sent an Apple floppy made in one of my classes to my old class and computer instructor on which I recorded me dictating my letter to them.
-
...doesnt that mean it should be possible to record an 8bit 22khz sample via the tape port...
Oh, if you needed an audio digitizer, then those would go through the C64 user port.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
-
How about a tape port to tape port transfer? Has this been done?
The cart port I guess would go at a speed of 8/8 * 1 mhz = 1 MB/sec. theoretical.
I did see a video of the introduction to "Dallas" played from a REU.
-
Has anyone here used a 64hdd ( http://www.64hdd.com )before?
If so, how did you like it?
-
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.
:D
-
Here is an interesting link.
http://en.wikipedia.org/wiki/Commodore_64_peripherals
-
@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...
-
If I remember correctly there is a location in ram that the REU constantly look at to check for commands, data, etc.
-
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.
-
Sorry to dredge :)
Here is a compilation of Load Star.
http://www.ramblehouse.com/loadstarcompleat.htm
-
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.
-
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.
-
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
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.
-
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.
-
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
-
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.
-
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. ;)
-
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.
-
Computer January 1985 has the Turbo Tape column.
The next issue has how it works.