SymbOS 4.0 released

[Prodatron]

Natively on SymbOS, the closest to this right now is to write your code in multiple Notepad windows and assemble it with SCC's native assembler. Improving the infrastructure for coding directly on SymbOS is definitely one of my long-term goals, however.

@prevtenet , that sounds amazing!
Your documentation of the SymbOS API
https://github.com/danielgaskell/scc/blob/main/doc/symbos.md
(link is only a fraction of the whole SCC doc)
is already better than my one one, haha!

[prevtenet]

I am still using the primitive DI:HALT methode for debugging in an emulator, if there is a nasty problem I can't debug in another way.

The other way I've done this is to insert some recognizable data (DB 1,2,3,4,1,2,3,4 or something) near the code I'm trying to debug and search for it in the WinApe debugger's memory view. (You can figure out the bank from the information given by SyMon.) Usually I only need to do this once per session, since subsequent loads of the app will tend to go to the same place.

You can assemble/compile a program directly to a native FAT16/32 partition on your PC and access it in WinApe with SymbOS directly.

I like this idea! Usually I just keep the disk editor window open and drag the executable into it. Either way, the whole process of compile/assemble -> load -> run only needs to take a few seconds on a PC.

• the ability to set breakpoints

That is not easy indeed.

This is a really interesting problem.

The "dumb" way to implement a debugger running natively on SymbOS would be to just insert some kind of CALL _DEBUG_ routine between every assembled instruction to save state and check for breakpoints, but this would bloat the code and run very slowly. A "smarter" way might be to create a sort of half-emulation layer where, to set a breakpoint, the debugger replaces the code with a specific RST or CALL (remembering the original, so it can execute it in single-step mode). In single-step mode, it reads and parses the instructions itself, either just by giving them to the CPU (for I/O and normal bitwise stuff) or by emulating them (for branches and stack operations).

...actually, that sounds kind of fun to write. Does SymbOS have any RST levels free that it could use as a hook, or would it have to use CALL?

[Prodatron]

The other way I've done this is to insert some recognizable data (DB 1,2,3,4,1,2,3,4 or something) near the code I'm trying to debug and search for it in the WinApe debugger's memory view. (You can figure out the bank from the information given by SyMon.) Usually I only need to do this once per session, since subsequent loads of the app will tend to go to the same place.

Cool now let me describe my way exactly:
I once place a DI:HALT. When the app is executed and the system is freezing at this point, I am opening the debugger, reactivate the interrupts and skip the HALT. Then I set a breakpoint to the DI:HALT address and replace it with 2 NOPs (0) - even in the source code (DS 2). As you mentioned, it is then usually at the same place, so when doing the next attempt, the breakpoint is already at the correct place.
I wonder which methode saves more time.

The "dumb" way to implement a debugger running natively on SymbOS would be to just insert some kind of CALL _DEBUG_ routine between every assembled instruction to save state and check for breakpoints, but this would bloat the code and run very slowly. A "smarter" way might be to create a sort of half-emulation layer where, to set a breakpoint, the debugger replaces the code with a specific RST or CALL (remembering the original, so it can execute it in single-step mode). In single-step mode, it reads and parses the instructions itself, either just by giving them to the CPU (for I/O and normal bitwise stuff) or by emulating them (for branches and stack operations).

...actually, that sounds kind of fun to write. Does SymbOS have any RST levels free that it could use as a hook, or would it have to use CALL?

Phew! But the idea is very interesting!
Yes, I was always afraid to use all RSTs as maybe I forgot something important, and then there is no-one left.
So RST#0 is still available.
But you only have 8 bytes to do something, and you could be in any 64K bank, while your debug handler is in a fixed one. Let's think about this, maybe it could be a cool feature!
( @noreccess64, thanks for starting this )

[norecess464]

Here, I'm only referring to programming directly from SymbOS for SymbOS.

Yes, SCC's internal assembler could be an option. So, multiple instances of the Notepad program, a Terminal to trigger the build, etc.

For debugging, I see two strategies:

• The classic breakpoint system, like used in Maxam and the others, which relies on an RST instruction to trigger. You must compile with that RST instruction, and when encountered, execution is paused, allowing you to inspect memory, disassemble code, and view registers. The only options are to resume execution or cancel debugging.
• The other strategy, as implemented by Orgams, simulates the Z80 to allow line-by-line tracing. Essentially, the debugger "emulates" the instruction pointed to by PC. This seems incredibly complex to implement, so I'm really impressed (and puzzled) by @m_dr_m 's achievement in this area.

Regarding the development experience, I guess it would be reasonable to require developers to compile with a small library that provides access to the OS's essential features, such as the memory manager, resource management, etc. But it's probably already exposed under another form

[prevtenet]

Regarding the development experience, I guess it would be reasonable to require developers to compile with a small library that provides access to the OS's essential features, such as the memory manager, resource management, etc. But it's probably already exposed under another form

Yeah, there is a standard library of header files for ASM development (and of course Quigs and SCC have their own libraries). Debug code could probably also be assembled into the app this way.

The SCC assembler derives from Fuzix and is a bit simpler than the WinApe assembler, so I don't think the standard ASM headers will work out of the box, but it shouldn't be hard to adapt the parts of the code you need.

So RST#0 is still available.

If you think the kernel design is mature enough not to need it in the future, it might be useful to define RST #0 as "available for advanced app usage." Possibly the kernel could set 0x0000 = 00 00 00... in each user bank by default, and it would be the app's responsibility to (1) check if 0x0000 in a bank is zero (i.e., not already registered by another app), (2) define their own jump vector there, and (3) clear it back to zero when done using it. Apps could then use RST #0 safely without requiring much (if any?) modification of the kernel.

[m_dr_m]

Essentially, the debugger "emulates" the instruction pointed to by PC. This seems incredibly complex to implement, so I'm really impressed (and puzzled) by m_dr_m 's achievement in this area.

Obrigado! As a side note, this was pretty fun to code. No stack usage allowed (no CALL, no PUSH/POP), only 5 8bits register to play with (some being used to count the machine time!).
The complicated part was to provide the line in the code source corresponding to the current PC.

[Prodatron]

If you think the kernel design is mature enough not to need it in the future, it might be useful to define RST #0 as "available for advanced app usage." Possibly the kernel could set 0x0000 = 00 00 00... in each user bank by default, and it would be the app's responsibility to (1) check if 0x0000 in a bank is zero (i.e., not already registered by another app), (2) define their own jump vector there, and (3) clear it back to zero when done using it. Apps could then use RST #0 safely without requiring much (if any?) modification of the kernel.

That is a good idea! The first 8 bytes are always 0 in all banks, so the rule would already work. I will add it to the documentation.

Obrigado! As a side note, this was pretty fun to code. No stack usage allowed (no CALL, no PUSH/POP), only 5 8bits register to play with (some being used to count the machine time!).
The complicated part was to provide the line in the code source corresponding to the current PC.

I was nearly falling from my chair, when I saw this on the Benediction party
NYYRIKKI did a Z80 emulator for Z80 but I guess this has been done independently.

[m_dr_m]

was nearly falling from my chair,

Too many b**rs!

[Prodatron]

Manfred made another video from his crazy CPC setup. I still have no idea how it is possible to connect so many stuff at the same time:



SymAmp running in SymbOS 4.0 playing Amiga MOD files.