Loci - my Oric storage emulation project

[Dbug]

I guess that also means that if you take the floppy out, put another floppy in, it will save the data on the new floppy since I don't believe there is any check if it's the same floppy

[iss]

The progress is saved automatically, so I never even considered the possibility of giving up with an error message. Maybe playing without saving should have been an option -write protected disk or user selection. Probably I was lazy!

IMO - you are not lazy, you simply made the perfect solution!

[Sodiumlightbaby]

Do you have to have the eject button actually shown at all on the line with the disk? I'm not sure how you navigate on the UI, but assuming it's like a UP/DOWN selection, the eject could just be a contextual option appearing somewhere at the bottom of the screen when the line with the disk is selected, "eject" is not an actual property or status, it's an action.

No, it doesn't have to be shown all the time. My initial idea was to have it show/enabled when a file has been mounted. You navigate with up/down/left/right so I was looking to organise the elements in a grid where that type of navigation would be natural. But you touch on an important point there, as I hadn't considered properly my mixing of control and status. I should aim to make it cleaner It could just as well be part of the file selection popup. I don't really know what situations you would use eject only (leaving the drive empty), except for OCD cleaness Changing to another image would not require an eject first.

Regarding the tape counter, that's a complicated one!

On real tapes, you would have to rewind to specific positions on the tape because the tape drive itself did not know the actual content of the tape, but on a digital device like yours, the rewind/forward could just be showing the "file number" and seek from one to the other, and have the status line show the name of the current entry on the selected tape.

Technically, when saving over a specific entry, you could even resize the content so the next entry is not deleted?

Ooh, that's quite a bit more intricate than I had first thought of. Yes, I was only thinking of doing something like filepos>>8 to get a rough counter from the file progress. Currently the CLOAD routine is very much a simple byte stream feeder. I looked at the TAP file format documentation I could find, with all the different variants, quirks and bugs, and I thought "hmm, perhaps not the parser I want to start with"
I'm not sure multi-session TAP with insert-saving is something I should get into before I have more experience with the format. As a stop gap, perhaps having a separate CSAVE file selection that defaults to <New file> for saving in run-mode and then integrate or work more on tools for TAP file inspection, splitting and merging when in setup-mode. So all saves would default to creating new TAP files. Ponder ponder.

As for tapes, there is another problem: the specific/protected loading routines
They are around 15% of commercial tapes, and several cases again:
- some call the "read byte" routine in ROM (TAP will run on both Oricutron and Euphoric)
- some call the "read bit" routine in ROM (TAP will only work with Euphoric)
- IIRC, some use their own system (then TAP file has to be hacked to call ROM routines), as a result, both Oricutron and Euphoric also allow loading WAV files.
- some use a timing system to skip a fake tape header while the tape is running, so the WAV file has to carry on being played while executing the program
- ...


It's a never ending mess isn't it

Yeah, anything interfacing directly with the VIA will be a problem. Currently I rely on patching ROM routines to direct CLOAD to CUmini instead of the VIA. I currently intercept at "read byte", so those might work. "read bit" I have not considered - any reason why they would do that? The timing system actually sounds possible, assuming they use the normal ROM routines once the timeout has occured. While we can't fake being the VIA, we can listen to what it is asked to do, e.g. when the motor is left running. Sounds like a potential interesting "weekend challenge" at some point.

Just a quick note on the protected files.

In the Cumulus all images are write-protected by default when they are mounted. This causes trouble if you are not aware and the program tries to write something (it might fail and hang, and you may lose your work), but the worst thing is there are three different ways to protect a file in that case: the flag in Cumulus, the flag in the disk file and the lock switch in the SD card itself.

I think it would be much better to keep only one of those, probably the OS write-protected flag in the file is more than enough. Granted you might accidentally erase or alter something, but it is not probable that you don't keep a backup in your hard disk.

I haven't dug deep into how hardware write protection is cascaded from devices through the USB stack, but it could be it's not easy to tell them apart once they get to us. But using the file system status as the one flag source for write protection sounds like the right thing to do.

I believe the SD card write protect switch is a hardware protection, maybe the lock icon could have a different representation to indicate if it's a software lock (file attribute) or hardware lock (sd card lock),

If I can get to the status through the USB stack, then yes. As the CUmini is USB base, many might be more likely to use a USB thumb drive with it than SD cards, although USB SD card readers are plentyful. Actually that's what I'm using at the moment (micro SD though w/o the write protection slider).

[Symoon]

Yeah, anything interfacing directly with the VIA will be a problem. Currently I rely on patching ROM routines to direct CLOAD to CUmini instead of the VIA. I currently intercept at "read byte", so those might work. "read bit" I have not considered - any reason why they would do that? The timing system actually sounds possible, assuming they use the normal ROM routines once the timeout has occured. While we can't fake being the VIA, we can listen to what it is asked to do, e.g. when the motor is left running. Sounds like a potential interesting "weekend challenge" at some point.

Regarding "read bit": some specific routines saved, hence load back, with a modified byte format. For instance, they reverse the data bits order. So they never use "read byte" in ROM, but use their own "read byte" routine, which calls... "read bit" in ROM

[Sodiumlightbaby]

Regarding "read bit": some specific routines saved, hence load back, with a modified byte format. For instance, they reverse the data bits order. So they never use "read byte" in ROM, but use their own "read byte" routine, which calls... "read bit" in ROM

That is interesting. Do you remember an example application/game?
And are the TAP files for these programs OK, or do you require WAV files to pass through the special encoding?

Based on the Basic 1.1 ROM disassmebly, I would assume the "read bit" routine is $E71C. Looks potentially patchable.
https://library.defence-force.org/books ... sembly.pdf

Code: Select all

Page 77
E71C 48 		PHA 		Cassette input timing.
E71D AD 00 03 		LDA $0300 	This routine waits for an
E720 AD 0D 03 		LDA $030D 	active transition of the
E723 29 10 		AND #$10	cassette input line (CB1 of
E725 F0 F9 		BEQ $E720 	6522). The time taken to
E727 AD 09 03 		LDA $0309 	receive it is measured using
E72A 48 		PHA 		timer 2 of 6522.
E72B A9 FF 		LDA #$FF
E72D 8D 09 03 		STA $0309
E730 68 		PLA
E731 C9 FE 		CMP #$FE
E733 68 		PLA
E734 60 		RTS

[Symoon]

That is interesting. Do you remember an example application/game?
And are the TAP files for these programs OK, or do you require WAV files to pass through the special encoding?

Based on the Basic 1.1 ROM disassmebly, I would assume the "read bit" routine is $E71C. Looks potentially patchable.

Yes, $E71C in ROM 1.1, or $E67D in ROM 1.0.

At some point, Loriciels games were protected like this. The game Doggy comes to mind. After the standard loading of the protection system, the programs didn't call the ROM anymore to load the protected parts.
The TAP files needed modifications, three types can be encountered:
- minimal modification: the "read bit" routine from the program is replaced by the ROM call (this won't work with Oricutron)
- more modifications: the "read byte" routine from the program is replaced by the ROM call, implying that the reversed bits from the protected parts had to be set in the right order again
- even more: cracked copies where the whole protection is skipped

[Sodiumlightbaby]

At some point, Loriciels games were protected like this. The game Doggy comes to mind. After the standard loading of the protection system, the programs didn't call the ROM anymore to load the protected parts.
The TAP files needed modifications, three types can be encountered:
- minimal modification: the "read bit" routine from the program is replaced by the ROM call (this won't work with Oricutron)
- more modifications: the "read byte" routine from the program is replaced by the ROM call, implying that the reversed bits from the protected parts had to be set in the right order again
- even more: cracked copies where the whole protection is skipped

Thanks that is a useful test. I see there are a few different formats available for it on oric.org. I think "read bit" patching of the ROM is possible, so will earmark this for when I get back to the TAP support. Thanks!

As for progress in general, I have been preparing a test for calling CUmini functions from the ROM, figuring out more of the basics of the STDIO-like interface inherrited from RP6502 etc. But I hit a snag in the existing ROM code. I've done something stupid with the IRQ. It works on the emulator but on the real hardware it doesn't fire periodically for the keyboard. It's strange as the IRQ line is asserted low continuosuly so clearly it's not getting to the proper IRQ handling routine. If I push NMI however, I can get it to trigger once.

Oh wow, I think I just had a case of "help solve your problem by explaining it to others" writing this post. My instinct was to suspect my IRQ/VIA code, but writing it all down now ... I bet I'm instead doing something silly in the bring-up-the-Oric code on the CUmini, leaving the IRQ line asserted I haven't tested the ROM on the real hardware since I got the font mirrored right so probably have an old left-over bug.

I'll check that tomorrow.

[Sodiumlightbaby]

Well, lost that bet
I must have been tired yesterday, because the IRQ line was not asserted at all. So the problem was my VIA setup. I took the timer1 setup from the the keyboard example, and it only loads the latches. Peeking at the Basic ROM disassembly, I could see that one was writing both the latches and the counter registers in the setup. And of course you need to write the high counter register to get the timer going. TIL

[Dbug]

I realize I did not really bother with the IRQ setup in the keyboard sample, it was reused from another code sample, so yeah you may have to change or tweak things for your specific scenario!

[Sodiumlightbaby]

I realize I did not really bother with the IRQ setup in the keyboard sample, it was reused from another code sample, so yeah you may have to change or tweak things for your specific scenario!

No blame on the original code, it's great! It has comments regarding assuming good interrupts already being set up. I just took the timer setup without much thinking. Bare metal/ROM development is a bit of a niche so perfectly understandable that general libraries and code examples don't cater to it.

[Sodiumlightbaby]

Alright!
We have a passing first test of calling the CUmini API from the ROM running on the Oric side! This is calling a unistd.h type "int write(fd, *str, len)" function on the Oric side with STDOUT as fd and a string typed in the TUI test as argument. That gets pushed as a CC65 fastcall on to the "API"/register interface at 0x03A0, picked up on the CUmini side and handled by the STDIO system there and gets printed on the OLED screen
Almost all of that is inherrited from the amazing RP6502 project so I'm not surprised that it works, but it feels good to see it all come together.

I can try to move on to implementing the directory listing and navigation functions now I think.

[Dbug]

Nice

Impressive progress!

[Chema]

This is looking seriously amazing !

[ibisum]

Very impressive progress! Can't wait to see what sort of doors this opens up once a few of us have this thing in our setup... whats the PCB plan? Are you going to make a production run ..

[Sodiumlightbaby]

Very impressive progress! Can't wait to see what sort of doors this opens up once a few of us have this thing in our setup... whats the PCB plan? Are you going to make a production run ..

Thank you for the kind words I've been trying to keep it fun and just the right amount of challenging, building small steps and solving small problems so that my internal reward system is fed right. So far it has worked well and given nice progress over time.

I need to make another PCB prototype run. What you haven't seen is that I need multiple tries to power on the Oric w/CUmini plugged in before it starts. I think I know what it is - the bus driver has OE hard wired, relying on DIR to control the HighZ state. At power on this is all wrong, massive bus contention and the Traco regulator oscillates or goes into protection cycles.

My plan is to get far enough that I'm confident the ROM based control interface will work and then sacrifice a slow IO (I2C) pin to make the OE not engage until we're booted and in control.

In other words, I'm collecting as many hardware fixes I can before ordering another protoype run. If that works well we have a release candidate.

As I wrote in the beginning of this topic, beyond some select testing, I'm not planning to sell or distribute devices myself. My plan is still to release all the material open source, allowing people to do their own small batch (5pc typically) prototype runs in worst case. But if anyone is interested in selling it, the production cost drops a lot for reasonably larger batches. I'm hoping it will be attractive to some of the esablished Oric-supporting sellers we have.

But I'm open to suggestions, e.g. if we need an initial run to get the ball rolling?

(Small reminder: still loads to do - release not imminent)