nocrew / ostis Goto Github PK

There is a problem in the Level 16 Full Screen Demo, in the first few seconds when it plays a sample.

Debugging the code shows that it writes to the PSG using three MOVE.L instructions:

MOVE.L (A1)+,(A4)
MOVE.L (A1)+,(A4)
MOVE.L (A1)+,(A4)

A4 is set to FFFF8800.

Currently, there is a 2-cycle delay added for each access to the PSG. Each instruction does two accesses, to there are four cycles added. A normal MOVE.L would take 20 cycles; these take 24.

Running the demo displays a shift. Supposedly 72 cycles for the three moves are too much. Random trial and error shows that 68 cycles is the right amount for the demo to run correctly.

Post links to interesting documentation here.

To clean up cpu.c a bit, putting cprint stuff into a separate cprint.c seems sensible

Some way to at least write bytes/words/longs to specific memory addresses when in debugger

I propose that ucode takes on the job of running everything around the instructions, and exceptions.
The state machine has one state chain for each instruction being executed. A state chain is a sequence
of microcode instructions (uop) being executed one after the other. Each uop taking 2 8MHz cycles,
and being run on even 8MHz cycles.

EA is just one or more sections of such a chain, and so are exceptions.

All of this assumes the full prefetch with IRC/IR/IRD is in place.

So the main role for an instruction is to setup the chain based on the instruction opcode (steps below may be optional):

1. Insert any uop:s that's needed before any EA
2. Append any EA chain that's relevant for reading
3. The instructions actual operation (ADD, SUB, Shift, a.s.o.)
4. Any EA chain for writing back to memory or such
5. Parts for setting flags
6. Remaining bits and prefetches before the instruction ends

The instruction is now only called to setup, after that, ucode takes over and steps through the chain.
If anything would happen that would change the normal execution, like for example a bus error occurs within
the EA steps, a bus error chain replaces the rest of the instruction chain, and ucode keeps on executing
just like before.

For TRAP this would essentially be the same thing, except the instruction would just insert the exception
chain for the TRAP exception into the chain straight away.

Other exceptions could be caught when ucode parses the end step, and if there is an exception/interrupt
pending, append the exception chain, and keep on running a bit longer.

Every uop is a callback into a function dealing with it. For steps 2 and 4 above, those are callbacks pretty
much the way they are in the EA code now. For 1, 3, 5 and 6, they would be provided by the instruction code.

The MMU has a lot of code that probably belongs elsewhere. We should agree on what, and where.

When a breakpoint has just triggered, it's not possible to resume execution with Ctrl-R. It seems like the breakpoint is triggered immediately again. Workaround is to do Ctrl-Z, then Ctrl-R.

The Phalanx Demo F1 screen doesn't work.

A short while after it switches to medium resolution, it tries to execute a 000F instruction. Which is illegal, so the CPU stops.

I tried a version 100 commits older than the current master, and the exact same thing happened.

The sound output is oh-so-close to being ok. I guess there are occasional gaps between audio buffer refills.

I don't know how to fix this, but it can't be rocket science.

In the current implementation of the clocked CPU, the cycles for exceptions go unaccounted for. The reason is probably that an exception occurs in the space between one instruction ending, and the next beginning.

We need some kind of state machine(s) for exceptions. In a way, they should behave just like ordinary instructions.

@larsbrinkhoff

From what I've been able to figure out, this seem to be a reasonable approach (GLUE line cycles):

 56c GLUE sets DE
 62c MMU sets LOAD
 62c Shifter loads IR1
 66c MMU sets LOAD
 66c Shifter loads IR2
 70c MMU sets LOAD
 70c Shifter loads IR3
 74c MMU sets LOAD
 74c Shifter loads IR4
 76c Shifter has copied IR1-4 into RR1-4 and shifted out the first pixel
 78c MMU sets LOAD
 78c Shifter loads IR1
 ...
 92c Shifter loads IR4
 92c Shifter has copied IR1-4 into RR1-4 and shifted out the 17th pixel
 ...
364c Shifter has copied IR1-4 into RR1-4 and shifted out the 289th pixel
366c LOAD IR1
370c LOAD IR2
374c LOAD IR3
376c GLUE kills DE
378c LOAD IR4 (nothing more is loaded now)
380c Copied IR1-4 into RR1-4 and shifted out 305th pixel
395c 320th pixel shifted out

Of course, with removed borders, things will be different, but as the normal case, could this work?

It's tedious to continuously check that all demos keep working when something in the video components change.

I plan to rip out the juicy bits from various demos, and put them all on a small test floppy. For each technique, display a screen and wait for a key press. The operator would then be able to quickly cycle through all screens and visually confirm they work.

Apparently ( :) ) the window icon is not suitable enough. It should be addable using SDL_SetWindowIcon() for each of the two windows, once someone provides one.

struct mmu is increasingly being abused for modelling hardware components. First diagnostics was added, and now interrupt handling has been included. Also, some entities that obviously model hardware components doesn't have a struct mmu. Most likely, struct mmu would be better off only handling MMU properties only.

I propose it would be a good idea to add a struct device for modelling all devices. Here are some things to consider for such a model:

• MMU interface
• Bus interface
• Interrupts
• Diagnostics
• Recording state
• Signals
• Connecting outputs and inputs to other devices
• Multiple instantiation (e.g. ROM, ACIA)
• Timer callbacks
• Periodic calls
• Reset
• Handling user/configuration/script commands

There are a few black pixels in the BIG Demo main screen.

They probably first appeared with the new shifter reload logic.

Make it possible to put a breakpoint on the base instruction instead of the explicit opcode (which is essentially the only possible way today, via watchpoints), so that one can break on any ROXL for example, regardless of its parameters.

This can (mostly) be done by using the actual function pointer value as the breakpoint trigger, because it's usually a generic dispatcher for the entire instruction handler.

The test system needs work. It should not require opening of a windows (but also not prevent it completely).

In combination with the clocked CPU work, I'm reworking it a bit with test helpers to make writing of tests a bit easier.

All this should make the Travis bit more useful too.

No input works. This problem was introduced in f803bc2

@stefanberndtsson is planning to convert the CPU component into a clocked design.

Would it be possible to jot down a few notes here every now and then to get a feel for what's going to happen?

Hi,

If I read the cpu emulation code correctly, divs/divu cycles are calculated simply by adding the worst case cycle count. If that's the case then the following code Jorge Qwik (ijor) will give accurate cycles for all cases of division:

http://pasti.fxatari.com/68kdocs/div68kCycleAccurate.c

Hope this helps,
George

It would be very tedious to implement EA calculation in every individual instruction. EA calculation normally happens at the start of an instruction, takes 0-18 cycles, fetches 0-2 program words, and reads 0-2 operand words.

Is there a plan to alleviate this? If not, I suggest creating a helper state machine.

This state machine would keep its own state. The instruction can call it from any instruction state to advance execution of the instruction and EA calculation in parallel, if necessary. In practice, I expect most instructions to just do a complete EA calculation in the beginning and process the rest of the instruction after that.

I imagine an API like this:

void ea_begin(struct cpu *, WORD mode); // Initiate EA calculation.
int ea_step(struct cpu *); // Return status: in progress, or complete.

I'll leave some details undefined. :-)

Something in 23e2394 broke medres. It's not reading data properly since then.

5aa12aa works fine.

This is only an issue with -K

VDI seems to show white output for characters in some cases. Noticable when opening File info and trying to edit the filename.

File format:

http://github.com/DrCoolzic/AIR/tree/master/pasti
http://info-coach.fr/atari/documents/_mydoc/Pasti-documentation.pdf
http://www.sarnau.info/posts/2011/pasti_file_format/
http://atari.8bitchip.info/STXdesc.html

There's no way to remove a label that you've created in the debugger. If you create a new one on the same address, only the latest one will be shown, but if you save them to a file, all of them will be included.

When running GEM under X11, they both display a mouse pointer. This is sometimes confusing.

I suggest that, when IKDB mouse reporting is on (as per a 0x08 command), SDL_ShowCursor(0) should be called. Conversely when mouse reporting is off (0x12), the X11 mouse can be shown again.

Currently building fails with the following errors:

lex expr.l
make[1]: lex: Command not found
Makefile:68: recipe for target 'expr.tab.c' failed
make[1]: *** [expr.tab.c] Error 127
make[1]: Leaving directory '/cygdrive/c/svn/ostis'
Makefile:48: recipe for target 'default' failed
make: *** [default] Error 2

This happens even after installing the proposed tools (flex, etc). When I changed LEX to flex in the makefile, compilation finished successfully. The attached patch fixes this for cygwin only.

0001-Minor-fix-for-compiling-on-cygwin.zip

There might be an issue around how register selection and data setting is done in the FDC. When booting, a read track request is sent now from TOS, which seems unlikely.

For some reason there are sporadic segfaults since the commit that introduced the audio output stuff (that doesn't work anyway). Regardless of turning audio on or not.

The tests subdirectory doesn't do much.

I propose to add automated tests which takes disk images, and verifies that they run correctly.

To do that, we'd need to able to inspect what is happening inside the emulator. I see that cpu.h has a debugging API which can be used for that.

We would also have to inject input from devices, e.g. key presses and mouse movement. ikbd.c already has functions for that.

Finally, to automate the tests, we'd probably have to disable SDL output.

When all this is in place, every commit can be automatically built and tested in a CI service like Travis CI.

It worked in 5b72e6b, but stopped working in the next commit 0d0c44e.

TL;DR: It works now.

Testing with make clean ; make ; ostis Arkanoid.st

a82e7c1: Ok
b220446: 20 bombs
bb61a9f: 20 bombs
0310565: 20 bombs
8912afd: 20 bombs
d42e8b8: 20 bombs
dcb8d87: 20 bombs
9bf6413: 20 bombs
3d65699: Ok for a while, then hangs with a zillion DEBUG: We're out of MFP interrupt with ISR still high
e3a2843: Ok, only occasional DEBUG: We're out of MFP interrupt with ISR still high
527c0e9: Segfault
fd36823: Strange white border, graphics updates erratically
6e396c7: Ok, no DEBUG messages

Just had to do it.

Instead of a compile-time switch.

There is currently no prefetch handling at all in the CPU, which means quite a bit of self modifying code will break.

More completely model the IRC/IR/IRD prefetch queue.

RGB and monochrome output goes to different pins. So screen_draw needs to be split in two: _rgb, and _mono. Only one should be active at one time. Which one depends on the monitor_sm124 flag.

Why does this matter? E.g. temporarily switching from colour to mono should result in some black pixels on the screen.

I believe the problem getting Phalanx Demo to work (see #77) is related to a missing MFP interrupt latency.