General Category > Programming

Pros & Cons of a universal Z80 loader, the BSOS (Bootstrap or Bullshit?)

<< < (2/3) > >>

zhulien:

--- Quote from: m_dr_m on 19:21, 21 October 21 ---Con: Yet another standard!


In which ways it would improve CP/M?

--- End quote ---


It lets you run the software on the OS you choose, as long as there is a loader for it - the goal is to keep it small and sweet, drivers would be available for some stuff perhaps.

zhulien:

--- Quote from: andycadley on 20:08, 21 October 21 ---I suspect that, much like CP/M, even little choices like where in the address space things need to live will break compatibility with some machines.


Even assuming you can use IM1, IY or the alternate registers breaks on a Sinclair machine for example.

--- End quote ---


I can understand IM1, but not sure why IY or alternate registers have issues - unless you are meaning you cannot use them when calling inbuilt ROM routines.

andycadley:
They're used by the ROM, including the interrupt handler and so things break if they don't hold the expected values (unless you redirect interrupts in IM2, which is it's own problem)


Other systems will undoubtedly have their own quirks and Z80 really, really doesn't lend itself to entirely relocatable code. So it quickly becomes something of a headache. I think you'd be better off just having a bunch of machine specific source code libraries providing machine independent functionality. Then you could quickly build for different target platforms while keeping a relatively generic code base.

1024MAK:
The workaround for address independent code (assuming the source code is available) is for an address translation program to run before jumping to the game/application code.

The non-use (or restoring the correct value) of certain Z80 registers only becomes a problem if you want to use the built in ROM routines or return to BASIC. It’s not needed if neither of these happens.

The bigger problem is the very different input and output I/O hardware….

Mark

m_dr_m:


First of all, Zhulien, I wish to reiterate my appreciation for your efforts about unification/standardisation.
The CPC scene is quite weak, and would gain to be boosted by the more general Z80 scene.
Now you could argue that programming for Symbos would be a great way to reach other scenes, but I have some strong concerns about that path, despite loving @Prodatron and his work.


Also, I have a use case: langage ports! (see https://www.pouet.net/topic.php?which=12155&page=1#c571455)


I'd like to have them on at least two "platforms":
* CPC Firmware (sometimes referred as "AMSDOS")
  * I'm used to a fast boot and don't plan to degrade my quality of life.
  * Plus, unidos opens new perspectives (e.g. scriptable ftp accesses).
* CP/M
  * So it could benefit to a broader community.
  * So we could benefit from a broader community.
  * Leverage nice CP/M shell with pipeline.


That would demand to neatly isolate the calls to libraries, and surely make some bridges.
Per chance, Orgams supports this at least:



--- Code: ---  if cpc:import "cpclib":end
  if cpm:import "cpmlib":end

--- End code ---


In turns, this sweet modularisation would ease ports to Symbos or FutureOs or non-CPC platforms.


Now, as other pointed out, the BSOS would be insuffisant. That's also my point about assembly-time dispatch: each platform would have its own I/O lib, its own ORG address, which solves the relocation issue.
But then, the BSOS seems to become unnecessary.


Am I missing something?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version
Powered by SMFPacks Reactions Mod
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod