Loci - my Oric storage emulation project

[Sodiumlightbaby]

2024-06-26 Notice: The project has changed title from CUmini to Loci


As I hit a milestone this week, I thought it would be an appropriate time to share my little Oric project: Working title «CUmini» - my take on emulated storage expansion for the Orics.

When I stumbled into the Oric universe laste last year while helping a friend, one challenge I hit was running those great new games, demos and applications many of the brilliant people here have been releasing. Many take advantage of the hidden RAM and the flexibility of floppies, requiring some type of floppy drive expansion device to work. And while that’s doable, thanks again to much brilliant work from members of this community, it seemed like the was a gap for an easily available, low-cost solution to lower the barrier for the Oric curious audience to get to that quality of software on real hardware.

CUmini is a small-ish (prototype is 65x53mm) expansion bus device for the Oric that primarily emulate ROMs, a Microdisc device for DSK floppy support, and CLOAD-ing TAP files. The main storage medium for TAP, ROM and DSK files is USB. USB is useful due to the abundance of dongle support if you want to use a flash card instead, and it opens up for interesting secondary features.

The milestone I hit this week was reliably booting from emulated Basic 1.1 ROM and CLOAD-ing Impossible Mission (im10.tap) from USB through emulated IO registers in page 3 (small patch to ROM)! I've been running some tests and ROMs, but this is the first time getting image files off external media, onto the device and running. Next I want to have the Basic ROM and device ROM work emulation coexist and allow me to get to DSK/Microdisc testing.

Current HW prototype is on Rev 1.1 and is so far working well and probably will do for completing the software development, but I have a growing list of fixes and improvements for a first release candidate. As a design goal is to enable low production cost, the design is almost completely SMD and device selection tailored for being assembled by a PCB production house. This should allow some economy of scale.

The prototype has a small display and navigation buttons for off-Oric UI, but it would be best for the low-cost goal to not require that interface for final operation. That’s still TBD though and not fully solved.

The RP6502 project by Rumbledethumps has been a great resource and inspiration for the backend of my project. The core platform is based on a branched and expanded version of the RP6504 RIA firmware for the Raspberry Pi Pico that does all the non-graphics lifting on the RP6502 Picocomputer.

There’s still loads of work todo, so there’s no need to ask when one can buy this. This is still in prototyping and exploration phase. It may easily hit a crippling problem and need to be scrapped. But so far, I’m enjoying working on this as a hobby project, and I’m encouraged by step by step progress. If it becomes useful, my plan is to open source both hardware and firmware to the community.

I’ll use this thread for sharing progress reports and development stories, as that’s also something I like to read from others.

Sodiumlightbaby

[Chema]

This is phenomenal!!

Please keep us updated

[ibisum]

Excellent work, thanks for the wonderful news about your project!

For the display BOM cut, wouldn't you just need to have a boot ROM that can be used to mount .dsk's, load .tap's and so on, a la Erebus/Cumulus? Or did you have in mind to maybe have a serial line interface that could just give the Oric a UI to the CUmini's microcontroller, where all this is being done? Or come to think of it, why not both ..

Exciting project! Sign me up for at least 4 when they're ready ..

[Dbug]

A cheap combo disk+tape is what has been missing for a while, looking forward to see how that develops

[Symoon]

Exciting news!

[kenneth]

If the RAM overlay memory is available, it's an interesting project.

[ibisum]

I'd say its highly interesting already, especially if that USB-C means we're going to be able to add peripherals, somehow ...

[Sodiumlightbaby]

Thank you all for the encouraging words

For the display BOM cut, wouldn't you just need to have a boot ROM that can be used to mount .dsk's, load .tap's and so on, a la Erebus/Cumulus? Or did you have in mind to maybe have a serial line interface that could just give the Oric a UI to the CUmini's microcontroller, where all this is being done? Or come to think of it, why not both ..

Yes, a boot time setup/config app is a must. Some API or way of calling the app again from basic shouldn't bee to difficult either. The question is how to support switching floppies (and switching sides) or tapes when something is already running without a display. I guess in worst case, that could be a more "pro" set of functionality. It's not unsolvable, it might even be possible to "freeze" the Oric for setting things up. We'll see how far we can make it, there's just a "few" other design changes to get through firs

If the RAM overlay memory is available, it's an interesting project.

Yes the desire to get to RAM overlay was a key goal and reason I started the project. The design approach I'm taking for floppy and tape emulation is to get as practically close to the original as I can so the existing ROMs and DOSs are likely to just work (fingers crossed). I'm leaving the VIA at 0x0300 alone so for tape things the basic ROM needs patching, but the prototype CLOAD patch is 19 bytes, 3 bytes NOP-ing of the call to synchronize and this patch to the "read byte from tape" subroutine.

Code: Select all

LDA #1
STA $0315
wait:
LDA $0315
BNE wait
LDA $0317
STA $2F
RTS

(Yes, currently I'm using some of the waisted registers of the Microdisc interface for tape).
Patching for basic 1.0 CLOAD shouldn't be any worse, and as the ROM function is emulated, running with or without the patch could be a config option for those days you want to get that real Oric tape experience.

I really like the potential benefits of cost and flexibility of emulating ROM, but the trade-off is that the 30 pin GPIO budget of the RP2040 is busted. I have moved "slow" IO (signals that don't require Phi2 accurate timing) like ROMDIS and RESET, as well as the button inputs, to an I2C IO expander. The initial HW prototype tried to use an auto direction switching lever shifter and driver (TXS0108) on the data signals to save one fast GPIO signal, but that did not work reliable. Don't use the TXS0108 on anything but very close range on-PCB signals - just being enabled on the bus screwed with the Oric.

So Rev 1.1 uses a more traditional 74-245 buffer with DIR control, with the knock-on effect that IRQ had to be moved to the slow IO group. This is currently my largest weak-point, and it will have to be tested well before I'm satisfied. My working assumption is that having a non-exact IRQ line should still work in most cases as long as the register IRQ flags are cycle exact. Some fail safes might need to be added due to this, but I think most of the floppy systems rely on polling anyway so I'm fairly confident (say 75%) it won't be a problem, but if it is then a redesign will be needed.

[Sodiumlightbaby]

I'd say its highly interesting already, especially if that USB-C means we're going to be able to add peripherals, somehow ...

Yes, as I hinted - there are some secondary functionality possible. The USB stack is TinyUSB, which has a limited but interesting set of devices supported. The given are of course hub and MSC for the storage, but in the HID area you have mouse support for example as something I want to prioritize. There is also an RNDIS class implementation so some limited networking functionality isn't out of the question, but now we're talking quite a bit out. I have been using the CDC class to get a make shift debug serial port going (as I spent all the pins on Oric stuff). Note that this is CDC host so it doesn't connect directly to a PC over USB, but gets you a real serial port if you plug in a usb-to-serial dongle.

Actually one idea has been to have a developer firmware version with the USB in Device instead of Host mode to allow pushing builds straight from a PC to the Oric. Again, I recommend checking out the RP6502 project for inspiration. But this is a bit of longer term dreaming, the board has so far run one TAP file and that's it. A few more bricks to lay on the house before we can invite to a pool party

[Dbug]

For the menu/setup/select floppy, I guess you could use some additional "hidden ROM" that you only map when you want to show the features of the system, but you would still need to save the zero page, stack, graphic memory, etc... to avoid corrupting the main application running.

That being said, most (all?) games are running on a single floppy, and I can't think of a single one that require a disk/side change, so most disk swap operations would be when using the DOS, or when "inserting a new game and booting it", so not catastrophic if the display is not restored.

Will the system support only one drive, or up to the 4 supported disk units (A, B, C and D) ?

[Sodiumlightbaby]

For the menu/setup/select floppy, I guess you could use some additional "hidden ROM" that you only map when you want to show the features of the system, but you would still need to save the zero page, stack, graphic memory, etc... to avoid corrupting the main application running.

Yes something like that should work. My biggest unknown, not being a seasoned 6502 nor Oric programmer, is how to safely and reliably intercept the processor. If I understand it correctly, RESB flushes the processor registers and states so probably only useful at startup, while IRQB does rely on the application having interrupts enabled. That should be most of the time, but not as reliable as I would have wanted.

That being said, most (all?) games are running on a single floppy, and I can't think of a single one that require a disk/side change, so most disk swap operations would be when using the DOS, or when "inserting a new game and booting it", so not catastrophic if the display is not restored.

Ok, that's encouraging.

Will the system support only one drive, or up to the 4 supported disk units (A, B, C and D) ?

It seemed easy to support all 4 drives when emulating a WD 1793, so yeah all 4. Is A-D the normal naming convention for Oric?

[Sodiumlightbaby]

How important is coexistance with other devices that have their register interfaces on page 3? My initial plan was to just expose emulated registers in page 3 for everything, but the limitiation on address decoding I have in hand means that would likely mean grabbing half or all (exept 0x0300) of page 3 address space blocking other devices

The alternative would be to adopt the RP6502 RIA register interface meaning access to any secondary functions whould go through a indirect register "portal". This would alow for much more data being accessible, but not allow for emulating legacy register interfaces.

In other words, only the Microdisc interface would be actually emulated and look to SW like the legacy device, tape would work with patched ROMs, and other things we expose would only be useful to new or patched SW. But this would allow for a much more narrow use of the address space.

Any preferences?

[iss]

Cool project!
About the coexistence with other devices:
1. it's important - allocating/reserving more $3xx addresses than needed just because to simplify i/o decoding will actually limit the usability of your device.
2. it's very important to use open-collector/drain outputs on the extension linked to Oric's control signal inputs!
Good luck, btw!

[Dbug]

There's a more complete list somewhere, but can't seem to find it, but there you go: https://wiki.defence-force.org/doku.php ... page_3_i_o

These are some of the reserved ports for some peripherals, and not being able to use other devices because address decoding is not done completely has been a major hassle on the machine: It's nice to be able to still use your speech synthesizer or modem with your floppy disk drive.

So yes, important to use a fewer registers as possible, taking half of the page 3 would be a seriously limiting factor.

Now, since it's your interface, and having it connected means you don't have to care about a physical Microdisc being connected, it means you can totally extend the usage of the existing registers for your own purpose, you could have a "I'm using these registers to control the microdisc" and put some other value to signify that "I'm using these registers to control the tape interface".

Like for example things like the number of tracks, the register is 8bit, but technically no floppy drive can access more than 82ish tracks, so you could give some special meaning to larger values to say that "you are addressing the tape".

[Sodiumlightbaby]

Good points folks. Minimum to the bone it is then
I'll stick to 0x310-31B as long as I can, and until its proven to be a problem, exploit the Microdisc unused/aliased registers at 0x315-0x317 and 0x319-0x31B for extended features. AFAIK the different DOS implementations stick to accessing the nominal 0x314 and 0x318 registers, making this hack possible. If you know better, I would like to hear from you

For know I'll stick to TAP loading on the first register set (to make patching simpler), and all the extended registers for div USB devices behind a portal in the second register set. Dbug's good idea of muxing the register use I'll keep as backup for if/when plan A fails. I want to keep the interface as stateless as possible.