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.

[eto]

DSKA1,2MB 15s2h80tr FAT12 SymbOS40-250131 v3.dsk

My Gotek is a external drive (no ABBA switch) and whenever I try to run it from B I get to the Desktop but no program can be loaded.

I tried both the 720K and 1.2MB version. 

Would it be possible to alter the image in any way so it also can be started from Drive B?

[eto]

My Gotek is a external drive (no ABBA switch) and whenever I try to run it from B I get to the Desktop but no program can be loaded.

@Prodatron I just recognized that I also cannot run SymbOS from Drive B if I use the normal DSK images. I thought I did that in the past but even the 3.1 version has the same issue. Is that generally not supported?

[Prodatron]

My Gotek is a external drive (no ABBA switch) and whenever I try to run it from B I get to the Desktop but no program can be loaded.

@Prodatron I just recognized that I also cannot run SymbOS from Drive B if I use the normal DSK images. I thought I did that in the past but even the 3.1 version has the same issue. Is that generally not supported?

The SYMBOS.INI of the disc version contains drive A as the boot drive and system path. You should manually run the control panel with Start->Run->Browse and change this in the "system" dialogue. I will have a look at this later and try it by myself, thanks for the hint!

[McArti0]

DSKA1,2MB 15s2h80tr FAT12 SymbOS40-250131 v3.dsk

My Gotek is a external drive (no ABBA switch) and whenever I try to run it from B I get to the Desktop but no program can be loaded.

I tried both the 720K and 1.2MB version.

Would it be possible to alter the image in any way so it also can be started from Drive B?

@Prodatron
Start Menu can remember % patch, but Desktop ShortCut cant do it. Instantly resolves to full path.  it would be better if it wasn't like that.

[eto]

The SYMBOS.INI of the disc version contains drive A as the boot drive and system path. You should manually run the control panel with Start->Run->Browse and change this in the "system" dialogue.

I'll try. thanks.

btw: I started from a real disk now and clicked around a bit. I can't change the name in the Highscore of Minesweeper. The keyboard is basically dead and I can only confirm "Prodatron".

[eto]

DSKA1,2MB 15s2h80tr FAT12 SymbOS40-250131 v3.dsk

My Gotek is a external drive (no ABBA switch) and whenever I try to run it from B I get to the Desktop but no program can be loaded.

I tried both the 720K and 1.2MB version.

Would it be possible to alter the image in any way so it also can be started from Drive B?

Start Menu can remember % patch, but Desktop ShortCut cant do it. Instantly resolves to full path.  it would be better if it wasn't like that.

Thanks.

That version boots and I get the icons but I can't start any program.  I can move the mouse and open the menu but if I click anything(menu or icon), then nothing happens. 

[McArti0]

That version boots and I get the icons but I can't start any program.  I can move the mouse and open the menu but if I click anything(menu or icon), then nothing happens.

DSKA1,2MB 15s2h80tr FAT12 SymbOS40-250131 v4_ForBootFromDiskB.dsk

This version?

[eto]

That version boots and I get the icons but I can't start any program.  I can move the mouse and open the menu but if I click anything(menu or icon), then nothing happens.

DSKA1,2MB 15s2h80tr FAT12 SymbOS40-250131 v4_ForBootFromDiskB.dsk

This version?

Wow, you are fast.

It only works if there is a disk in drive A. As soon as I remove the disk the programs no longer will start. 

[McArti0]

Try unconnect drive A... 

[eto]

Try unconnect drive A... 

What would be different compared to no disk in drive?

I can try that tomorrow.

[Prodatron]

Wow, you are fast.

It only works if there is a disk in drive A. As soon as I remove the disk the programs no longer will start.

Thanks @McArti0 for your support!

@eto, oh, that sounds strange.
In WinApe it is not a problem to set up SymbOS only with drive B. After booting you will just see the minimal desktop, then you select and open the Control Panel manually, set "Boot Drive" to B and system path to "b:\" and save the settings.

McArti0 is right, the Extended Desktop doesn't accept the system path % placeholder for Desktop Icons. I have to check again, what's the reason for this, and if this can be changed.

Attached you will find a normal 180K disc image, which boots SymbOS just from drive B including the full stuff, and that works at least in WinApe, without drive A. Currently I don't have a drive B connected to my real CPC, but if necessary I can add this again during the next days, if the issue is still existing on real hardware?

You cannot view this attachment.

[eto]

Attached you will find a normal 180K disc image, which boots SymbOS just from drive B including the full stuff, and that works at least in WinApe, without drive A.

That perfectly works! Thanks.

[McArti0]

That version boots and I get the icons but I can't start any program.  I can move the mouse and open the menu but if I click anything(menu or icon), then nothing happens.

DSKA1,2MB 15s2h80tr FAT12 SymbOS40-250131 v4_ForBootFromDiskB.dsk

This version?

Wow, you are fast.

It only works if there is a disk in drive A. As soon as I remove the disk the programs no longer will start.

  On WinAPE runs good.

[harzretro]

At friday i made a small 'computer-exhibition' with lot's of computers ... beginning from zuse z22 (parts of them) over a olivetti programma 101 to high performance computers ....

And there i showed also symbos - and the people were exited!
Especially with the symamp and multitasking - and also playing the Doom port!

But i didn't had enough time to prepare 'real'  good stuff .....

[Prodatron]

And there i showed also symbos - and the people were exited!
Especially with the symamp and multitasking - and also playing the Doom port!

Thanks Axel, that's very nice to hear!

I still have to prepare something for you, I will write you soon!

[harzretro]

And there i showed also symbos - and the people were exited!
Especially with the symamp and multitasking - and also playing the Doom port!

Thanks Axel, that's very nice to hear!

I still have to prepare something for you, I will write you soon!

Ohaaa, i'm looking forward for it

Ohhh, and i've to say: Symamp with a good sound system and the sound of second reality - it is awesome!

Couldn't believe that this is a CPC ....