MMC-ORIC

This is the right place to discuss on how to implement hardware vsync, adding a VIA or AY chipset, puting multiple roms, or how to design a new flash expansion card.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Greetings,

I was quite tempted to open another thread for this, so we don't get too out of topic, so if anybody feels this should be done, please feel free to move this message.

I already said I am not a hardware guy, but I work with some hardware people that are used to deal with microcontrollers and such hardware, so I approached one of them and asked about this matter.

His idea (based on what I know and my own vision, which might not be correct) is that it should be possible and "quite easy" to build an emulator of the disk based on a PIC microcontroller. He says there exist modules to connect the PIC to SD cards and USB pendrives and even with LCD displays that could build the part in charge of selecting a disk image.

The PIC code (that could be done in C), should just emulate the behaviour of the controller, reading the values written to page 3 through an input port and outputting data as necessary. Extra I/O lines in ports can be used to generate or read the ROMDIS, MAP, IO, IO CONTROL and IRQ signals. The PIC should just implement some kind of finite state machine emulating the behaviour of the disk drive.

I am talking by memory, so I might be wrong, but I suppose it could be possible to connect the adress/data buses to input/output ports and use the IO CONTROL line to indicate the PIC when it has to read the value in the address bus and act accordingly. For instance, when reading a sector in a microdisk controller, my code (Fabrice's, really) does this:

Code: Select all

read_data 
   lda $0318 
   bmi read_data 
   lda $0313 
   sta (pbufl),y 
   iny 
   bne read_data 
   inc pbufh 
   jmp read_data 
So it seems the PIC should set bit 7 on the data port whenever address $0318 is accessed and there is a new byte to transfer. When the Oric's CPU reads $0313 it should put in the data port the value of that byte.

This is an infinite loop, which is exited with the interrupt service routine that follows:

Code: Select all

irq_handler
.(
  bit $030D
  bpl fdc_irq
  pha             ; cancel any VIA interrupt when overlay ram is active
  lda #$7F
  sta $030D
  pla
  rti
fdc_irq 
   pla      ; get rid of IRQ context 
   pla 
   pla 
   lda diskcntrl 
   sta $0314   ; disables disk irq 
   lda $0310   ; gets status and resets irq 
   and #$7c 
   sta __status 
   rts 
.)
 
Not quite sure about how this works, but it seems that when bit 7 in the data read in $030D is 0 it means that the 256 bytes of the sector have been read. It also seems that the FDC controller generates an interrupt whenever this happens.

Ok, this is all quite complicated, and might be wrong (can anybody elighten me?) but this is the most complicated function. However the code must be there in Euphoric, so we might have a reference of how this is done in the FDC part of the emulator.

Unfortunately I was not able to spot the difficulties of such a design, so my colleague could not dig any further. Some difficulties that may exist:

The PIC should be fast enough to put the correct value on the data bus whenever a given address is put in the address bus. Also should be fast enough to read the data bus whenever needed. Is there a need of some kind of fine-timing here?

Are the lines on the Oric side TTL? Any restrictions here?

We need to add the part of the EPROM. Is there any difficulty I don't see here?

This guy told me that there should be no problem reading the dsk file and even keeping a whole sector into the PICs memory.

Anything I could ask/comment?

Cheers
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Chema wrote:comment?
Well, it is pretty much what I was thinking as well, emulate the behavior of what happen when writting in the registers, and don't care about things like real world stuff like timings or how it is supposed to behave if you do that incorrect things. Really an hardware emulator of a microdisc, nothing more, which means that if people develop using that it may not work on a real microdisc - but if it works on a real microdisc it would most probably work on the emulator :)
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Dbug wrote: Well, it is pretty much what I was thinking as well, emulate the behavior of what happen when writting in the registers, and don't care about things like real world stuff like timings or how it is supposed to behave if you do that incorrect things. Really an hardware emulator of a microdisc, nothing more, which means that if people develop using that it may not work on a real microdisc - but if it works on a real microdisc it would most probably work on the emulator :)
Yep. I suppose that you might also monitor phase2 and R/W lines to be sure you put/read data when it is stable and also be sure to leave the bus alone when other areas of memory are being selected. Maybe there could be issues with timings here.

If they are not, why can't the PIC also deal witht he EPROM? It can have the Microdisc eprom in memory and deal with access to those areas when the eprom is selected?

Well just something to think about... There are also other boards with micros running microLinux, which are not too expensive and might do the work.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

If timing is not critical then the PIC could do the job. Even though timing isn't real critical for many operations I still think you will find there is a minimum response time for other operations.

After some thought, a single clock cycle to respond wouldn't be required due to the 6502 needing to load an instruction before it would read or write from/to the controller. That doubles the number of instructions a PIC could run before data has to be ready.

Since PICs can be driven at much higher speeds than the ORIC it shouldn't be too big of a problem. However, if you are writing the code in C you'll need to do a lot of testing to be sure.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Chema wrote:If they are not, why can't the PIC also deal witht he EPROM? It can have the Microdisc eprom in memory and deal with access to those areas when the eprom is selected?

Well just something to think about... There are also other boards with micros running microLinux, which are not too expensive and might do the work.
It certainly could handle the ROM/RAM/EPROM or whatever switching. But a PIC has a limited number of built in ports and if it runs at a different speed you also have timing issues between the 6502 bus and PIC.
I think you'll find that switching the pages in a small FPGA will be less complex than adding more inputs for the PIC... which is why I was trying to find a way of doing things without the PIC.

It's really easy to interface to a couple ports with a PIC... but it has a limited number of pins for I/O and you start having to reuse (multiplex) pins which requires external hardware... which is just what you were trying to get rid of.

One of the reasons the PICs work so well for the C64 and Atari is that they only need serial I/O for the SD, serial I/O for the Atari bus, a couple input lines for the buttons selecting disk images, and a serial out to run the display. That's 7 or 8 I/O lines.

If a pic just interfaces to a drive controller to imitate a disk drive it's 8 (?) lines for the bus and a couple for the PC serial connection. (using the existing disk emulator as an example)

If you have to imitate several 8 bit ports, SD I/O, buttons, and a display (assuming you want something like the Atari or C64 has)... thats a lot of pins. Even if you multiplex pins then the PIC has to do more operations and you run a greater risk of having timing issues.

On the Tandy CoCo most software uses a couple DOS calls to read and write data so custom software called DriveWire is able to emulated a drive over a serial connection to a PC.

And speaking of the CoCo, the Speech and Sound Pak had a microcontroller on it. Data wasn't guaranteed to be valid for several clock cycles which made programming it a little tougher.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Torlus wrote:Very interesting idea, honestly ;)
<snip>
JamesD wrote: People seem to have their hearts set on using an MCU.
I don't see why using a MCU seems horrific to you ;)
I won't argue about writing code for MCUs and such compared to the 6502, but if your main concern is firmware updates, then most MCUs have some "bootloading" support and self-flashing capabilities, so you could perform firmware updates using the SD card itself : no need for external programming tools.
It doesn't seem horrific to me. I just think people don't understand it's going to be more complex than they think. If you have to add too much hardware to do interface to a PIC then you might be better off without it.

BTW, I thought of a way to speed up the drive emulation done with the 6502. Hardware FIFOs on the data read/writes.
One nice thing about FIFOs is there are already open cores to do that in an FPGA and the FIFO size could be adjusted according to the size of the device.

I also thought about the interrupt issue. Interrupts are usually disabled for other operations during any timing critical operation like reading/writing from/to disk so I don't think it would break software.

And instead of having the emulation code on a split ROM/RAM page on the interface, just copy the code to a RAM page. It would simplify the design and allow local variables to sit outside of RAM. If page 0 were needed, the contents could be saved before and restored after.
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Post by Torlus »

I think I understand what you mean. For such an interface, you either need an EEPROM+CPLD (or PAL)+MCU, or a FPGA that may contain the whole thing.
The second solution is probably cost-effective as FPGAs are cheap nowadays, but the board design and manufacturing may harm, especially if the number of units produced at the end is low (and I think it will, after all, there seems to remain few people still interested in the Oric nowadays :) ).
The first solution requires more components and will probably cost more at the end on a per-unit basis, but well, I know that designing and building the required board will be easy, as most parts will be thru-hole (DIP and PLCC packages). It could even be prototyped on a breadboard.
Well, that's probably only a matter of personal taste, but I fell more comfortable with this approach.
And depending on which FPGA you choose, you may need to add an external serial flash for its design loading, voltage level translators, etc. so it would probably not be as cost-effective as it could seem.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Torlus wrote:I think I understand what you mean. For such an interface, you either need an EEPROM+CPLD (or PAL)+MCU, or a FPGA that may contain the whole thing.
The second solution is probably cost-effective as FPGAs are cheap nowadays, but the board design and manufacturing may harm, especially if the number of units produced at the end is low (and I think it will, after all, there seems to remain few people still interested in the Oric nowadays :) ).
I think getting to the 50 quantity might be a bit difficult. I figure 20 is certainly doable if the cost is reasonable. That's the problem though... you cut the quantity in half and the cost of the board could double.
Without a design to base an estimate on it's impossible to see how many holes and what size would be needed.
The first solution requires more components and will probably cost more at the end on a per-unit basis, but well, I know that designing and building the required board will be easy, as most parts will be thru-hole (DIP and PLCC packages). It could even be prototyped on a breadboard.
Well, that's probably only a matter of personal taste, but I fell more comfortable with this approach.
Most of the SD & CF interfaces started out like that so it shouldn't be an issue.
And depending on which FPGA you choose, you may need to add an external serial flash for its design loading, voltage level translators, etc. so it would probably not be as cost-effective as it could seem.
What I'm seeing is a JTAG connector and the FPGA is flashed with the program.
A simple JTAG interface to a PC is no big deal to build.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Chema wrote:His idea (based on what I know and my own vision, which might not be correct) is that it should be possible and "quite easy" to build an emulator of the disk based on a PIC microcontroller. He says there exist modules to connect the PIC to SD cards and USB pendrives and even with LCD displays that could build the part in charge of selecting a disk image.
All the pieces to do that are out there and that part is quite easy.
The PIC code (that could be done in C), should just emulate the behaviour of the controller, reading the values written to page 3 through an input port and outputting data as necessary. Extra I/O lines in ports can be used to generate or read the ROMDIS, MAP, IO, IO CONTROL and IRQ signals. The PIC should just implement some kind of finite state machine emulating the behaviour of the disk drive.
It can be done in C as long as the MCU is fast enough and yes, it's just a state machine.
I am talking by memory, so I might be wrong, but I suppose it could be possible to connect the adress/data buses to input/output ports and use the IO CONTROL line to indicate the PIC when it has to read the value in the address bus and act accordingly. For instance, when reading a sector in a microdisk controller, my code (Fabrice's, really) does this:

Code: Select all

read_data 
   lda $0318 
   bmi read_data 
   lda $0313 
   sta (pbufl),y 
   iny 
   bne read_data 
   inc pbufh 
   jmp read_data 
Here is where you run into timing issues. Look at the number of clock cycles between testing $0318, reading data, and testing $0318 again.
The MCU has to output $0318 and output to $0313 within a few clock cycles. I don't think $0318 would need changed again until the read is done... just $0313. However, the MCU has to know when a byte has been read from $0313, the MCU must wait for the end of the 6502 clock cycle before updating it again and finally it must output the new value in time for the signals to be stable for the next load from $0313.
As long as you can do that, that is the toughest part of reading data.

If you make the hardware the PIC talks through buffer the data and deal with the different clocks for the two chips then the software is much easier to write. A FIFO would also simplify things for the MCU since it wouldn't need to know when it's safe to output data for $0313 again.
If the FIFO just signals the PIC once it's empty then the PIC could update the status at that point.

Just remember, when the MCU writes to a buffer between the Oric and the MCU, the data can't be updated to the Oric side until the end of the clock cycle. Same goes for writes from the Oric to the buffer. The MCU doesn't get the data until the end of the cycle.
Ok, this is all quite complicated, and might be wrong (can anybody elighten me?) but this is the most complicated function. However the code must be there in Euphoric, so we might have a reference of how this is done in the FDC part of the emulator.

Unfortunately I was not able to spot the difficulties of such a design, so my colleague could not dig any further. Some difficulties that may exist:

The PIC should be fast enough to put the correct value on the data bus whenever a given address is put in the address bus. Also should be fast enough to read the data bus whenever needed. Is there a need of some kind of fine-timing here?
If the PIC itself must detect a port is being read and update the info it's very timing critical. The PIC won't be signaled until the address on the bus is stable. The PIC must then detect which address is being accessed, read the data, and do the appropriate operation. In the case of a read the data must be valid within the same clock cycle in time for the bus to become stable and the read to complete. Very nasty.

If you buffer all ports between the two you don't have to update things in such a critical manner since you can pre-load registers, but you must still signal the MCU all commands that are written to the controller and when reads take place the appropriate registers must be updated within just a few clock cycles.

The worst case is the last byte read in a sector. The Oric program checks the status, reads the last byte and then reads the status again at which point it is informed that was the last byte of the sector. On the other side, the MCU waits for a byte to be read, it's signaled when that is read, it updates the buffer and discovers that is the last byte of the sector. At that point it waits until the last byte is read from the buffer and updates the status register. Just remember, the time between updating one register and another is only a few clock cycles and you need to make sure the time for an interrupt and all required processing can take place in the desired time. If you can do that, no problem.
Are the lines on the Oric side TTL? Any restrictions here?

We need to add the part of the EPROM. Is there any difficulty I don't see here?

This guy told me that there should be no problem reading the dsk file and even keeping a whole sector into the PICs memory.

Anything I could ask/comment?

Cheers
The Oric uses TTL levels. The only issue will be learning at what point the data on the bus is guaranteed to be stable. I'm guessing that's the issue people had with a simple IDE interface.

I'd use FLASH but an EPROM would work. No issue there, just a simple circuit for switching ROM, RAM and FLASH or EPROM in and out of the memory map.

The one significant thing being left out here is how to also add mass storage larger than a floppy. The C64 and Atari get around it because it's handled by the device and the computer just talks to it. The drives can even have new commands.
An interface that emulates a drive controller is limited by the max size of a sector, track, and number of tracks... not to mention the DOS. If you want mass storage for that new adventure game with hundreds of pictures you are stuck swapping disk images manually.
Same goes for anything that requires more space than a floppy.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

JamesD wrote:The one significant thing being left out here is how to also add mass storage larger than a floppy. The C64 and Atari get around it because it's handled by the device and the computer just talks to it. The drives can even have new commands. An interface that emulates a drive controller is limited by the max size of a sector, track, and number of tracks... not to mention the DOS. If you want mass storage for that new adventure game with hundreds of pictures you are stuck swapping disk images manually.
Same goes for anything that requires more space than a floppy.
It may or may not be a problem, mostly because to my knowledge the biggest Oric software ever made all fit on one single floppy.
If at some point we wanted to do larger demos or games, we would still have to handle the fact that most people have only one drive - please insert disk 2 to continue -, still by default a Microdisk controller board supports up to 4 drives, so technically the floppy emulator could allow to mount 4 DSK images, one for each virtual drive :)

I really doubt people would try to develop a massive adventure game that would not work on "normal" orics, because even great games like what Chema or Twilighte are writing are watched only by few people - counting the fact you can play them on emulators.

Any software that would work only on this floppy emulator would have a seriously reduced target audience :o

Now technically, if we assume that it is a simple emulator that does check for boundaries, I seem to remember that the WD1793 just have simple 8 bits registers for the track and sector registers. This means that you could probably read and write on a virtual floppy containing 2 sides, each one with 256 tracks, each track containing 256 sectors, each sector being 256 or 512 bytes long.
2x256x256x512 => 67108864 bytes => 65536 kbytes => 64 megabytes

This should be enough, and could indeed be practical for development purpose.

About the registers access, as you said I believe this bus instability is the root of all the problems we had with every single oric interface. Having some buffering is probably a good idea, this would solve your problem with the timings of the interface. You would write "not ready" in $318, would write the value to be read in $313, would switch to "ready" in $318 and almost immediately write "not ready" again in $318 (just the time for the 6502 to detect the ready value, pass the branch, read $313... so when it go back to the "is byte ready" loop the flag is correct back to "no ready").

Does that make sense ?
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Dbug wrote:I really doubt people would try to develop a massive adventure game that would not work on "normal" orics, because even great games like what Chema or Twilighte are writing are watched only by few people - counting the fact you can play them on emulators.
The point is, you can't. It's not even a consideration.
Any software that would work only on this floppy emulator would have a seriously reduced target audience :o
Exactly how many people do you think have Oric drives?
If you wonder why few people play these games on the real hardware I'd say that's the number one reason why they don't.
The drives are very rare and when they do pop up the collectors (that will probably never even use them) crawl out of the woodwork to bid the price into the stratosphere.
People could probably afford a new interface easier than an old one and they could certainly find one easier.
Now technically, if we assume that it is a simple emulator that does check for boundaries, I seem to remember that the WD1793 just have simple 8 bits registers for the track and sector registers. This means that you could probably read and write on a virtual floppy containing 2 sides, each one with 256 tracks, each track containing 256 sectors, each sector being 256 or 512 bytes long.
2x256x256x512 => 67108864 bytes => 65536 kbytes => 64 megabytes

This should be enough, and could indeed be practical for development purpose.
And exactly how does the Oric DOS know how many tracks, sectors, sides the currently mounted disk has? You want an interface with buttons to swap disks. Exactly how does the Oric know what gets mounted and when?
The Oric would have to read the directory... but how do you handle the number of files that would hold?
In theory it works. In practice... it's another matter.
You have to write a new DOS anyway.
About the registers access, as you said I believe this bus instability is the root of all the problems we had with every single oric interface. Having some buffering is probably a good idea, this would solve your problem with the timings of the interface. You would write "not ready" in $318, would write the value to be read in $313, would switch to "ready" in $318 and almost immediately write "not ready" again in $318 (just the time for the 6502 to detect the ready value, pass the branch, read $313... so when it go back to the "is byte ready" loop the flag is correct back to "no ready").

Does that make sense ?
It makes sense but if the MCU is fast enough you never have to write not ready to the port except when a sector is being read.
Everything else should be fast enough.

A command comes in, the MCU executes a switch case statement to decode the command. (C language)
If all that is required is to update a pointer (stepping tracks or sector) and the data is in the buffer it just updates some variables and waits for the next command.
If it needs to buffer more data, it writes not ready to the status port.
If it's a read, it writes the first byte to the port for the read (or more if there is a FIFO).
It writes ready to the status port.
The MCU gets a signal when the data has been read (or the FIFO is empty) and it writes the next data to the port.
If it's the last byte, it detects the read and writes whatever status is required to signal the end of the sector and/or not ready.
I would need to know more about the last part to tell what needs to happen.

The software state machine is rather simple. The MCU to Oric interface is where the complexity lies. On the C64 and Atari it's a piece of cake. Here... not so much.

Some thoughts...

The MCU should be clocked much faster than the Oric. Since the Oric provides no clock signal that is faster you have a separate clock and an asynchronous interface. The buffers have to be able to accept data from the MCU at any time and know when it's safe to update the status to the Oric bus.

You have to allow writes as well. Data is grabbed by the buffer at the end of the Oric clock cycle to guarantee it's valid. The data can't be sent to the MCU bus until the end if it's current clock cycle. At that point the data is valid and an interrupt is triggered. A FIFO doesn't require an interrupt until it's empty.

If a FIFO is used, it must have a mechanism to allow it's contents to be dumped in case a read or write is aborted. Software may not actually do this but it SHOULD be handled.


The status port content must ALWAYS be valid. This was not the case on the Speech & Sound Pak and the status might say ready when the device was not. That's ok if the software knows it won't be valid right away but in this case the software does not so it has to be right. (the truth is, the S&S Pak was a PITA because of this)

You *could* have the hardware buffer interface set the status to not ready after every operation automatically. At least when required which would be buffer empty (FIFO or non), Command written, status read, etc... are all possible sources that would trigger this.

The asynchronous interface is non-trivial for someone like me but an experienced engineer might be able to do it easy.

The interface will require an FPGA, not a PAL or GAL. I have a bunch of decent sized GALs and they are not large enough for that sort of thing.
They are good for replacing several of standard 74LSxxx chips. A breadboarded IDE port could be done with 3 to 5 standard chips, and a GAL, but not this.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

JamesD wrote:Exactly how many people do you think have Oric drives?
If you wonder why few people play these games on the real hardware I'd say that's the number one reason why they don't.
That was not the point. I was not saying people did not play these games on the real hardware. I was saying they did not play these games AT ALL despite the fact you can play to them on emulators.
I'd say there's about 95%+ of Oric usage done on emulators these days, because they are compatible enough to run everything, including all the games and demos.
And yes people don't do that on the real orics because as you said the drives in working conditions are extremely rare.
My point was that doing a game that would work on a specially extended device would reduce the audience because until emulators support that, it would reduce the potential audience to exactly the number of people who have the actual device.
JamesD wrote:The drives are very rare and when they do pop up the collectors (that will probably never even use them) crawl out of the woodwork to bid the price into the stratosphere.
People could probably afford a new interface easier than an old one and they could certainly find one easier.
That's true, and that's why I am pushing for something that is compatible with existing software: The product get value just by existing. Not by allowing some hypothetical future software developed for it.
I'm also pretty sure it is the kind of device that would sell correctly on eBay, perhaps as a collector package ready to use with a SD card containing ready to boot images for some games and demos.
JamesD wrote:And exactly how does the Oric DOS know how many tracks, sectors, sides the currently mounted disk has? You want an interface with buttons to swap disks. Exactly how does the Oric know what gets mounted and when?
Well, the way it is working at the moment, is that the first track of an oric floppy is always in the format of Oric DOS 1.0. The controller ROM use this information to load the boot sector and run it.
All you need is to have this boot sector be able to load the extended format, which should not be a problem for most games and demos because they don't use the DOS at all: They just use a custom read sector routine.
If you can build the extended floppy image disk on the PC (should be easy by modifying Tap2Dsk), then you can do something that boots on it.

Having a real dos that handles large amount of data is more delicate, even if some people (Symoon) have done some work related to having an existing Oric DOS support directories.
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Post by Symoon »

Dbug wrote:
JamesD wrote:Exactly how many people do you think have Oric drives?
If you wonder why few people play these games on the real hardware I'd say that's the number one reason why they don't.
That was not the point. I was not saying people did not play these games on the real hardware. I was saying they did not play these games AT ALL despite the fact you can play to them on emulators.
I'd say there's about 95%+ of Oric usage done on emulators these days, because they are compatible enough to run everything, including all the games and demos.
And yes people don't do that on the real orics because as you said the drives in working conditions are extremely rare.
My point was that doing a game that would work on a specially extended device would reduce the audience because until emulators support that, it would reduce the potential audience to exactly the number of people who have the actual device.
People don't have disk drives because they are too rare to find and old, but seeing the prices they sell and the questions we have at the CEO, you can be sure people are looking for drives.
And I was surprised, when I joined the club 14 years ago, to discover I was almost the only one still using tapes (over 150 people at this time).

BTW, you have an example of hardware evolution, it's called the Super Oric, bringing new graphic possibilites and so on. It exists for more than 5 years now (if not much more), has loads of articles in the magazine, but people that have one must be 4 or 5.

Having a real dos that handles large amount of data is more delicate, even if some people (Symoon) have done some work related to having an existing Oric DOS support directories.
Well I think we already reached the maximum with Sedoric (you can format a disk using Euphoric, which would not be supported by real hardware, but that uses the maximum size), and IIRC it was around 1MB.
Swapping directories wouldn't allow any more room on the disk, we'd have to swap bitmaps but it would require a serious re-writing - not sure it would be possible easily.
Fabrice worked on Randos years ago, because Randos already had directories, and was more suitable to his hard-drive project. IIRC, he planned using 2MB partitions. Maybe some information can still be found on his website.

EDIT: information about Randos 2002 here:
http://www.oric.org/index.php?page=comm ... ail&id=150
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Ok, maybe one stupid idea....

I have been taking a look at an old book I have about the Rockwell6500 microcomputer system which is based on a R6502 (any difference with the Oric's CPU?). The book has some time diagrams and one of them shows the timing for reading/writting data from memory or peripherals.

I am not sure if I understood everything, but it seems that:

For reading the address in the bus has to be stable when the R/W signal goes high. After a max of 575 ns the data in the data bus has to be there and stable during a min time of 100 ns, when the phase 2 clock goes down, because (I think) it is at that moment when the CPU reads the data. Data must be hold therefor a min time of 10 ns, typically 30 ns.

Maybe the MCU can use the R/W signal to know when to read the address bus and put the data when the phase2 signal goes high (somewhere at the middle of the cycle) and until it goes down plus those additional 30 ns.

For writting data to the peripherals the address should be stable when the R/W signal goes low. The data will be in the bus after a max of 200 ns, typically 150 ns, since the phase2 signal goes high, and can be read when the phase2 signal goes low again, if it can notice the event and read in 10 ns!

The MCU could use the R/W signal (or the rising of phase2) again to know when to read the address and read the data when the phase2 signal goes down.

Ok, maybe only in my imagination you can time with that precision, maybe it depends on the hardware, so it should be studied, but it would be a matter of triggering some kind of interrupt at R/W and/or phase2 lines?

Just some thoughts... don't take them too seriously... It is quite late here in spain!
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

The MCU should not monitor the R/W directly. The hardware will use a delay of the line as a final enable to let the circuit know the data is valid. That is done in hardware by sending the signal through a gate or two to delay it the proper time.

The interface will signal an interrupt when needed.
Post Reply