sd cards & stuff

[highwayman]

hello people.
had a lot of trouble signing up here, but now i managed:

have you seen this?
http://www.luigidifraia.com/c64/dc2n/index.html
looks like a dropin to me.

also:
http://pontoppidan.info/lars/index.php?proj=mmc2iec
not a dropin, but good enough to make me want to add an IEC interface to the oric

i have a disassembly of the vic20 kernal,
is there a disassembly of an oric rom floating around?

[mmu_man]

The tape thingy looks interesting, but keep in mind:
- the tape levels and frequencies might differ (probably not much at the same epoch), the modulation also.
- the protocol also is likely different (ORIC sends several sync bytes, then a header with the name, ...).
meaning at least the firmware on the board will have to be changed.
There are other tape emulators for other machines around.
One thing that (at least for ORIC) prevents from making a fully automated thing is the fact that while on saving the name is in the header, the name of the wanted prog is never sent for reading, so either you have to select it manually (LCD+buttons, preset, ...) or you have to simulate playing the whole list of files (which can take some years I suppose for 1GB at the usual tape speed ).

As for the disk emulator, the problem is different.
On C64 the disk controller was "intelligent" (it even had a microprocessor), and received commands from the computer to open a file, load part of it, write, close... So it's easy to fake the device at that level and stay compatible with existing software.
On the ORIC, disk drives were more low-level (just an FDC, some glue and a boot ROM). So the DOS had to be loaded from the disk, and executed by the cpu to access the disk. So to handle an MMC one would have to almost rewrite a DOS. Add to that the fact that there were at least 4 different controllers (microdisk, telestrat, jasmin, cumana...) and even more DOSes, so many progs only worked with one of them anyway.

For the ROM, there were likely some books about the ROM.
If you really want to you can check
http://revolf.free.fr/oric/atmosrom.zip but it's not really commented and lacks labels.

[JamesD]

You can already convert a tape image to an MP3 and play it back on an MP3 player or over a sound card so I don't see a tape emulator as very useful and more expensive. Sure it might allow saving but you can capture to wave form with a sound card and convert it to an MP3 or tape image.
You could add a high speed cassette mode that would transfer faster by dropping in a new ROM but it still doesn't address the overlay RAM issue. You can get away with much higher speeds to/from a sound card than tape.

The Atari and C64 disk emulation devices are also overkill. They would cost way more than the required UARTs for what I proposed and would need all new code anyway.

What those projects might provide is code to support FAT16 or FAT32. It could be compiled and then optimized. But then I think a couple of the Apple II projects already provide that.

[highwayman]

You can already convert a tape image to an MP3 and play it back on an MP3 player or over a sound card so I don't see a tape emulator as very useful and more expensive. Sure it might allow saving but you can capture to wave form with a sound card and convert it to an MP3 or tape image.
You could add a high speed cassette mode that would transfer faster by dropping in a new ROM but it still doesn't address the overlay RAM issue. You can get away with much higher speeds to/from a sound card than tape.

The Atari and C64 disk emulation devices are also overkill. They would cost way more than the required UARTs for what I proposed and would need all new code anyway.

What those projects might provide is code to support FAT16 or FAT32. It could be compiled and then optimized. But then I think a couple of the Apple II projects already provide that.

scuse me?
the thing about the tape emulator is it derectly handles TAP format.

as for the disk emulator, it costs about £5 to build one - why is that so much?
and the software is mostly handled by the interface so the oric just needs high-speed file read & write - not so different to the existing tape routines.

i'm making one anyway - so i'll look int how i can add IEC bus to the oric without messing anything up.

[mmu_man]

the thing about the tape emulator is it derectly handles TAP format.

I honestly don't think the TAP files used by C64 and those used by ORIC are compatible. Just because they use the same extention doesn't mean they have the same headers.

[JamesD]

You can already convert a tape image to an MP3 and play it back on an MP3 player or over a sound card so I don't see a tape emulator as very useful and more expensive. Sure it might allow saving but you can capture to wave form with a sound card and convert it to an MP3 or tape image.
You could add a high speed cassette mode that would transfer faster by dropping in a new ROM but it still doesn't address the overlay RAM issue. You can get away with much higher speeds to/from a sound card than tape.

The Atari and C64 disk emulation devices are also overkill. They would cost way more than the required UARTs for what I proposed and would need all new code anyway.

What those projects might provide is code to support FAT16 or FAT32. It could be compiled and then optimized. But then I think a couple of the Apple II projects already provide that.

scuse me?
the thing about the tape emulator is it derectly handles TAP format.

as for the disk emulator, it costs about £5 to build one - why is that so much?
and the software is mostly handled by the interface so the oric just needs high-speed file read & write - not so different to the existing tape routines.

i'm making one anyway - so i'll look int how i can add IEC bus to the oric without messing anything up.

The 64 has a serial disk interface and built in support for it. The Oric doesn't. That means you still need to add a UART and software to support it but it's doable but you'd need to rewrite the software for the device unless you want to load at the speed of a C64 disk drive. However, it's more expensive than just adding a UART, hooking directly to the SD/MMC card and writing a driver for the Oric

That tape interface takes advantage of the fact that the C64 leaves the analog circuitry for interfacing to tape external. The Oric provides that internally and unless you bypass that on the Oric you'll also need to convert the signals to/from tape levels.

Good luck reaching that price point... that's around $10 US I believe. After s&h on just the parts it will probably cost more than that. And that doesn't count a circuit board which by itself would cost more unless you did a production run. Do a complete parts list and I think you'll find your estimate to be optimistic.

[JamesD]

This is the circuit required to attach a regular tape recorder to the C64. It's built into the Oric.
http://members.tripod.com/~petlibrary/cassette.html

This is all that is required to hook up a C64 to a PC serial port. It's not so simple with the Oric.
http://www.ktverkko.fi/~msmakela/8bit/c ... ex.en.html

[highwayman]

i know all about hooking stuff up to a cia or bus - i'm a hardware engineer.
i think it may be possible to get an IEC bus from the existing cia, and pushing up the speed wouldnt be a problem afterwards.

that said, obviously i'm the only person actually interested in anything like this and your all happy with 3.5inch disks & cd-walkmans so i wont talk about it again unless i do it first.

and btw, you dont want the 6502 running low-level filesystem work when an 8 or 12mhz microcontroller can be doing it for you - not if you want decent speed anyway.

[mmu_man]

i think it may be possible to get an IEC bus from the existing cia, and pushing up the speed wouldnt be a problem afterwards.

It's a VIA in the ORIC :p
Once again, there is no concept of serial bus in the ORIC ROM, the only thing that comes close to this is the cassette port.
Anything that doesn't interface with existing ports require modding the ROM to have it supported.
And the cassette port is plain dump.

that said, obviously i'm the only person actually interested in anything like this and your all happy with 3.5inch disks & cd-walkmans so i wont talk about it again unless i do it first.

No, that's why we are checking mmc cards...
but again all require writing host support code, that's why we are investigating reusing existing DOS code to keep the few compatible software.

and btw, you dont want the 6502 running low-level filesystem work when an 8 or 12mhz microcontroller can be doing it for you - not if you want decent speed anyway.

Yes but you need a way to ask it what you want, and there is nothing in the ROM that can.
At worse as I said you could think about saving an empty basic prog or variable with a name to send the name of the prog you want to CLOAD... but that's hackish.

[JamesD]

i know all about hooking stuff up to a cia or bus - i'm a hardware engineer.
i think it may be possible to get an IEC bus from the existing cia, and pushing up the speed wouldnt be a problem afterwards.

Well, the existing cia is already used for most of the ports on the system but it might be possible. It would be a heck of a lot easier if they had socketed the cia though.

The Telestrat required an additional CIA to add more ports so I have my doubts.

that said, obviously i'm the only person actually interested in anything like this and your all happy with 3.5inch disks & cd-walkmans so i wont talk about it again unless i do it first.

It seems to me several people started posting about an SD/MMC card over a week before you did so it's not like you were the first here to talk about it.

I think anyone that still uses an Oric would love to see ANY SD/MMC interface no matter who designs it.

I just pointed out several flaws in using the the existing design of those SD/MMC interfaces on the Oric. That's all. Don't take it personal.

and btw, you dont want the 6502 running low-level filesystem work when an 8 or 12mhz microcontroller can be doing it for you - not if you want decent speed anyway.

Well, it's been done on the Apple II and Speccy and it's far faster than the old floppies. I guess it depends on what you mean by decent speed though. No matter what way you implement an SD/MMC interface the bottleneck is still the speed of the Oric CPU.

The microcontroller will be faster at handling the FAT file system but you have to run a protocol between the drive and the Oric so you are not doing away with all the overhead but changing from the SD/MMC protocol to another protocol. No matter how fast the microcontroller interfaces with the SD/MMC card it still has to wait for the CPU to talk to it and then talk back.

Using the CIA requires you to either select your port whenever you want to access it or keep interrupts disabled during data transfers. That leaves you a choice... slow down the data transfer and negate any gain offered by the microcontroller or eliminate any chance of multi-tasking while any communication with the drive takes place.

Memory mapped I/O doesn't require switching a CIA and only requires semaphores in the DOS to give exclusive access to the device during transfers. Other tasks or interrupts can continue to run while a program accesses the drive. *If* DMA were added (something that has been demonstrated on the Speccy) you could transfer data as fast as the Oric RAM can handle it.

Even if you use the CIA, you still have to modify the DOS which won't fit in the existing eprom so you still need some sort of upgrade that swaps the DOS ROM in and out. You still have to add control for the overlay RAM or people are stuck with 48K which is less than if you have a floppy drive.

Now, if anyone comes up with an accelerator for the Oric, a direct interface will benefit. A C64 type drive interface will be stuck at the same clock.

Quite frankly, I'd just as soon work with other people on this than split our efforts... but at the moment I don't think you've worked out any of the details.

[JamesD]

I guess I should have said VIA instead of CIA.

[JamesD]

Once again, there is no concept of serial bus in the ORIC ROM, the only thing that comes close to this is the cassette port.
Anything that doesn't interface with existing ports require modding the ROM to have it supported.
And the cassette port is plain dump.

You are quite right... cassette isn't an interactive protocol between devices and even if you dumped it's code you couldn't squeeze such a thing in it's place.

You might be able to squeeze in a bootstrap routine that loads DOS from the drive into that space but you still need overlay RAM to put it in and that requires additional circuitry. You would also be without cassette routines to load your old tapes.

[mmu_man]

*If* DMA were added (something that has been demonstrated on the Speccy) you could transfer data as fast as the Oric RAM can handle it.

Unlike the C64 or AppleII, ORIC has no DMA handling at all, and the ULA has full control of the bus when the cpu doesn't use it AFAIK (it must send column addresses to refresh the dynamic RAM and of course scan the video buffer.
And since the control signals which could eventually be used to disable the cpu to replace it by an external one (like the SuperCPU board for C64) aren't available on the expansion connector it's not possible in a simple way.
The only way one can do DMA is by completely disabling the internal RAM and having a faster one on an exp board which access can be interleaved with the CPU and ULA accesses.

[JamesD]

*If* DMA were added (something that has been demonstrated on the Speccy) you could transfer data as fast as the Oric RAM can handle it.

Unlike the C64 or AppleII, ORIC has no DMA handling at all, and the ULA has full control of the bus when the cpu doesn't use it AFAIK (it must send column addresses to refresh the dynamic RAM and of course scan the video buffer.
And since the control signals which could eventually be used to disable the cpu to replace it by an external one (like the SuperCPU board for C64) aren't available on the expansion connector it's not possible in a simple way.
The only way one can do DMA is by completely disabling the internal RAM and having a faster one on an exp board which access can be interleaved with the CPU and ULA accesses.

To do DMA you'd have to stick the controller partially between the ULA and the system so the ULA could pause the DMA/CPU and the DMA could pause the CPU.

It can be done but there may be some problems with some add on hardware.

[mmu_man]

Except the RDY pin which IIRC can be used to step the cpu is just grounded, doesn't come from the ULA.
Besides, the ULA can't stop doing the display, and the cpu will probably not like loosing it's clock. It can be done maybe but would need complex circuits to make sure it's safe (cf http://www.6502.org/mini-projects/clock ... ching.html ).