Loci - my Oric storage emulation project

[Sodiumlightbaby]

Is there a reason why the user has to choose between one and the other - compared to having LOCI adapting is reading at each ROM call?
Just asking because I'm not sure may users will be aware that, if a TAP file is not working, they might have to try at bit-level - this is really a specialist thingy.
Okay, not even tested and already complaining, I know

He he no worries. I think I was partly aiming for minimal patching and partly needed a way to test it myself. If it's ok to just leave all the patches on in one mode, we can change the mix - it's a simple adjustment.

[Sodiumlightbaby]

Here's Tyrann side A TAP file for bit-level reading on ROM 1.1, hoping it works! Only six bytes are changed from the original data on tape.
Tyrann_UK_A_bit-crk_atmos.tap

Yes it works!

[Symoon]

Yes it works!

Great! LOCI is, along with Euphoric, the only emulator/device able to read TAP files at bit level, like real Orics

[Sodiumlightbaby]

I've pushed some small changes from Symoon's feedback. "Byte" mode has been changed to "Auto" where all patches are applied. I've kept the "Bits" choice for now and having the control visible. No new release, these small changes will just roll up in the next relelase.

[Sodiumlightbaby]

Tiny update. Play time has been spent mostly slowly trying to debug some odd behaviours. On a local branch I have managed to restore _most_ of the original monitor developer functionality like accessing Oric memory. Odd thing is I manage to get the writing to work, but the reading just stops after a few bytes.

And today I found a new interesting oddity. While initializing a new pair of test devices, the "normal" w/o a display claimed to get a timing scan of 20, which didn't work when running some applications. Well, perhaps a dud LOCI board. Initialise a new one, and got the same result. Turns out having the display connected or not changes the timing result from the TIOR scan. Ruled out a few possible causes but still not near a resolution. So one more on the WAT list

[Dbug]

Ignore my email (but you can check the version of the game if you want), the game is failing to run on the real Oric because... I'm dumb: I added the possibility to print out the commands used by the player, so testers can give me easy to use reports about what they did... on an emulator it outputs the content to printer_out.txt but on the real Oric if the printer is not connected it just hangs.

So it's not like the game was failing to load on LOCI, it was just that it was trying to send data (facepalm).

Which brings the question: Is is possible to test if there is a printer and if it's ready?

[Sodiumlightbaby]

So it's not like the game was failing to load on LOCI, it was just that it was trying to send data (facepalm).

He he I can relate

Which brings the question: Is is possible to test if there is a printer and if it's ready?

I don't know the control characters for the typical printer but could it work to strobe out a non-printing byte and just check the ack?

[Sodiumlightbaby]

And today I found a new interesting oddity. While initializing a new pair of test devices, the "normal" w/o a display claimed to get a timing scan of 20, which didn't work when running some applications. Well, perhaps a dud LOCI board. Initialise a new one, and got the same result. Turns out having the display connected or not changes the timing result from the TIOR scan. Ruled out a few possible causes but still not near a resolution. So one more on the WAT list

Mystery solved. And it was simply that the scan triggers screen updates that was serving as the actual value iteration delay for each tested value.

[Dbug]

That's a typical Quantum bug: When the observer impacts the observation

[iss]

That's a typical Quantum bug: When the observer impacts the observation

Indeed, Schrödinger's cat for Oric

[Sodiumlightbaby]

Got a little further with my second conundrum, the monitor read and verify function. It's not critical for normal operation, but a rabbit hole that I fell into

The funtionality in question is for the monitor where you can get listing of and write to Oric memory locations. This is implemented by pointing Oric to temporary copy loop patches in page 3 address space. The write patch has been restored to work like on RP6502, but the read/verify section fails after a few (varying 0-10) bytes. After a of debugging, trial and error I have narrowed the reason down to random BRK instructions being executed.

So it looks like I have uncovered an IO read/write weakness where back-to-back read after write may not be serviced or served badly (with zero/BRK). Exaclty why I don't know yet, but one step closer after tonight.

[Dbug]

With this type of issue we can clearly see the superiority of using some programmable device instead of legacy type components, makes it much easier to tweak timings and update the behavior to match various machines with different tolerances without having to push a hardware update

[Sodiumlightbaby]

Well, I have come as close to the bottom of the spurious BRK during monitor writes problem I think I want for now. The core of the issue was simply that I was running out of time for handling writes.

For reads the 6502 sets up the address and read/write flag early in the PHI2 cycle so we have a relative good margin to figure out what to do with it and serve the data on the bus when the clock goes high.

Writes are a bit more tricky as yes, we get the address and read/write flag early but the data isn't put on the bus until that end portion of the cycle. The problem was basically waiting to do the write processing until the data is ready, but then running out of time to catch and handle the read in the next cycle.

The solution (or improvement at least) was for write handling to start all the needed housekeeping with decoding the address and branching into the relevant register emulation as soon as the address was ready early in the clock cycle, then wait there for the data to come in and quickly run just the data dependent actions.

This made it _almost_ perfectly work, but now and then it would still miss a deadline so this fix is still marginal and I was running out of ideas.
...
So I duct-taped it by poiting the BRK/IRQ vector back to the routine it came from. Problem "solved"

While we know we still have a marginal implementation, it will only trigger when you do a write and then a read immediately on the next cycle to the IO page. I _think_ that can only happen if you are executing code in the IO page (as in the op codes are in page 3), and only these read/write/verify monitor functions should do that and for those we have duct tape!

What's the usecase for this monitor read/write/verify thing? Well, for a developer it could be used to ctrl-alt-del when something wrong happens and then peek around in Oric memory to see what's going on. Poking also works, but we don't have clean resume yet so not quite useful yet. Same for loading Oric RAM over serial or network.

Patches pushed, but don't see the need for a release for them. I would like to add some fun stuff too to make it worth it

[Dbug]

Nice you found some reasons behind the madness

As you noticed, I've not participated much recently, I'm trying to get as much progress as I can on my game so I can get a version that people can test.

I'm actually thinking of making a trim down version of the game that just does booting, showing some information, loading some stuff, saving it, so we can test that the core game booting/loading/saving runs fine on most systems.

In theory the code is supposed to run on 48K Oric 1, Atmos, Telestrat, Pravetz, with either Microdisc or Jasmin, but I've never actually tried!

[Sodiumlightbaby]

As you noticed, I've not participated much recently, I'm trying to get as much progress as I can on my game so I can get a version that people can test.

No worries! I love following your work too

I'm actually thinking of making a trim down version of the game that just does booting, showing some information, loading some stuff, saving it, so we can test that the core game booting/loading/saving runs fine on most systems.

Sounds like a good idea. Quick test with good feedback (well perhaps without requiring a printer )