Cartridge Device for Oric

[barnsey123]

NOTE: I'm not a hardware guru and know very little about the oric's "inner workings" so don't shoot me! This is just an idea...

Has anyone ever thought about the possibility of adding a cartridge device to the oric-1/atmos? The old atari 8-bits (also 6502 based) had them (among others) and today, people are doing amazing things with them see http://www.atarimax.com

I'm thinking that this would be more than just a fast disk to load software from, they could also act as gateways to other devices (ethernet/usb etc - this is what they are doing in atari land). The carts could also be programmed from your pc. We could probably use these existing atari carts (just re-flashed with whatever oric-specific software that is required)

If they could plug into the expansion port we would also get access to our oric's full 64K (take away a few K for a bootloader/driver). Maybe could also be used as additional RAM expansion (above 64K)

So, hardware guys, what do you think?

[highwayman]

learn about hardware - specially 8bit cpu's & memory addressing.

[barnsey123]

I've just been shot!

Am reading page 114 of the AUG and fumbling in the dark...

A hypothetical device that plugged into the expansion port could be visible to the oric in the same way the microdisc is - it would contain a ROM that would load itself into the top 8k of RAM (#E000->#FFFF) - like a micrdisc - but instead of saying "insert system disk" and loading DOS it would load some software from the flash memory on the cartridge (this could be anything, surely) - it could even be DOS-like providing new commands to access the device - I would guess that as long as it fits into the memory of the Oric that is reserved for DOS (#d400->#ffff) then anything else is possible.

I envisage a board (containing the bootstrap ROM) that would map the I/O lines on the expansion port with the appropriate I/O lines on the cartridge device.

Am I talking nonsense?

[Chema]

Am I talking nonsense?

No, I don't think it is nonsense. It should be possible to do it, and it could even have some commands to switch between different 16K banks on the overlay area ($c000 to $ffff).

What I wonder with this, and also the SD based card with the possibility of loading tap images is if it is the way to go. Don't get me wrong, it would be a wonderful and interesting project (both will be), and quite useful. But first I wonder the amount of software that would benefit from such a design. We have very little new software already, and it is not probable (yet possible and very interesting) to develop something that will only run with such dedicated hardware, and maybe on emulators.

Second, the part of loading tap images without having to fight with the real machine bugs and issues will be more interesting, probably. Having all the software in one SD and loading it quickly and reliably will solve many problems, but with the drawback that, as it is not emulating a disk drive, all the software making use of it won't run.

I am biased here, as most of the software I developed and I may be interested in running on the real Oric (WAVE, for instance) requires a disk drive.

Still think that Cumulus is the way to go, but I am not sure if it will ever be popular enough (I mean, that most of us have it). I dream of a redisign to avoid the CumulusBus and have something that we could build for reasonable price, if we get organized.

Just my two cents in this discussion...

[highwayman]

the biggest problem is using ROMDIS to put external code into the upper memory area,

i'd be very surprised if you could find a single game that didnt use rom routines,
and trying to flip between an external rom and the original on a running system isnt easy without causing a crash.

the other option is to rip the tape routines out of the oric rom and use the space to add your own code - then map that rom inplace of the original.
only problem with that is the copywrite pussy's who are scared shitless that a police deathsquad is gonna smash the front door in at 6am because they re-used about 7k of some code written in the 1980's !!!!!


the 8bit atari & commodore machines are different because the main rom checked for expansion roms in free area's at boot - so you could "add" code instead of having to replace it.

[highwayman]

btw, adding ethernet hardware would be pretty easy now - probably only needing 2 chips.

combine that with a nas/fileserver & you end up with a nice solution providing the software doesnt take too much space up.

[Godzil]

i'd be very surprised if you could find a single game that didnt use rom routines,
and trying to flip between an external rom and the original on a running system isnt easy without causing a crash.

It's far from impossible, that's how floppy drive works. You have to be carefull the first time to set interupts vector, and you can't toggle romdis without external hardware, but the ROM is everything but not indispensable.

[Chema]

I am not a hardware guy, as you all know, but I guess that it could be something similar to what a disk controller does: disable the ROM, boot from an internal EPROM with probably some small DOS with basic routines in page 4. When the user selects a tap file, use custom routines to load the data into the Oric's memory (the lower 48K), switch back to ROM and call the program (this code is in page 4, so no problem here, I think).

The bank system will surely need specific code to handle it, but as we are talking about new software... it would be something similar to what we do when using overlay ram, I guess.

But the complex part of all this is interfacing with the Oric bus, as it's always been, so if this is solved, microdisc emulation is very near... In fact, IIRC that was the issue with Cumulus.

And Cumulus is there, working, just a bit expensive and/or difficult to build due to the use of two PCB cards (Cumulus and Cumulus bus) and other components... am I right?

[highwayman]

there is no problem interfacing with an 8bit bus,

the only time you get problems is if your project is 3.3 or 1.8v such as modern FPGA's because the oric is 5v.

however, some FPGA's have 5v compliant i/o and another solution is to use buffers.


forget loading tap files - the oric wouldnt know what to do with them - the loader would need to decode them into binary.
better to store the prog's properly as files with a header like on floppy's and tapes.

also, loading a prog into ram and then banking the original rom in is good for most games - but not perfect.
some games load stuff as they run - they would need constant access to the loader routines.


i think it may be a good idea to se how much space can be found in the oric rom rather than using 2 with bank switching.

[Dbug]

there is no problem interfacing with an 8bit bus,

the only time you get problems is if your project is 3.3 or 1.8v such as modern FPGA's because the oric is 5v.

however, some FPGA's have 5v compliant i/o and another solution is to use buffers.

Famous last words

Even the original Oric peripherals don't work reliably on all the Oric models.

The Oric bus is known for being crappy and unreliable. Even today I received some mail update on some address decoding card being made by a CEO member, using only standard oldschool components (LSxxx, transistors and whatnots), and it does not behave the same on all Oric he has because the signals are so mushy that instead of having nice impulses you get rounded signals that may or may not be detected as high or low as the correct time.

[barnsey123]

Regarding the bus problems...
If the signals on the bus vary from machine to machine then I wonder if ANY device on the expansion port would have to include some sort of "tuner/amplifer"...a little dial perhaps like on old TV's/Radios?

The user would have to "tune in" the device to suit a particular oric! How cool would that be?

Sorry, it's been a log day.

[highwayman]

the bus problem is caused by poor smoothing of the 5v supply and the fact that the oric uses a 7905 negative regulator.

if the electrolytic caps are good - as in *not* 25+ years old, and your interface does not use an external supply there are no problems - i used to build loads of memory mapped interfaces - most with 6821's

that and keep the ribbon cable down to a couple of cm if you can.

[barnsey123]

I meant "long" instead of "log"...

The reason the cartridge device appeals is the flexibility ( a disk drive is just a disk drive, it doesn't do anything else) but a cartridge can be anything (there are cartridges which perform as USB adapters, ethernet connectors and so on - and yes, disk drives too)

Perhaps there are just too many problems (not even considering the software that would have to be written - by whom, when etc)
But there is also the appeal of just banging in a cart and playing a game instantly. Still, it would keep us off the streets...

@highwayman "..copyright pussys.." I agree.

[highwayman]

you dont want to be constantly "banging" stuff in,
the ribbon connectors fail after a while if you keep plugging & unplugging them.

you need to keep in mond that what you do needs to run on simple software because the oric has limited space for code.
i wouldnt touch usb for that reason.

infact i think any project these days could be "helped" by interfacing through a microcontroller.
most are more powerfull than the oric & much faster - they could do a lot of the hard work to simplify the software on the oric.

ethernet for example, the microcontroller could deal with the low stuff like the stack,
the oric could just send or request to port numbers or send ping etc and let the interface do the dirty work.

same with drives - let the interface do the Ext2/FAT32 stuff and leave the oric to just push or request files by filename.

[Dbug]

Ok, let's assume we have no cost problems, and that we want this thing to be as compatible as possible, it would mean that basically it has to load tapes, if possible non modified.

A possibility would be to have a device that embeds a copy of the Atmos ROM, with the only changes being the tape loading code (at the same addresses so code that calls directly the 'get header', etc... would work).

So the device would play with the ROM and overlays like the standard Microdisc unit does, showing the copied ROM instead of the real ROM, and I guess some page 3 address can be used to select one of multiple pages of memory (possibly mapped from a flash unit) and then copied to normal rom with standard system variables in page 2 updated to reflect a real tape load, and when done give back control to the calling code as if it was back from an actual CLOAD"" ?