From Newsgroup: comp.sys.apple2

Several years ago I was dinking with a Laser 128, and later with the
SimSystem IIe emulator which had a similar - it seems, string-hacked - firmware. I got to thinking about the occasional programs I'd try with
the 128 or SimSystem IIe that would blow up.

Sometimes, these were old file-cracked single-load games, which I was able
to get to work by using the old System Master to load an Apple ][ ROM, and then run them. That didn't always work.

From what I understand, the hardware isn't quite enough like the Apple //e
or //c, that a //e or //c ROM could be used unmodified to drive a Laser,
or a Laser ROM to drive a //e or //c - but I suspect there isn't much difference. I came up with the idea that perhaps, since most if not all
of the source to the parts of at least some versions of the //e and //c firmwares DO have the source published (excluding FPBASIC, which isn't
really relevant to this apart of having to be brought in from a //e or //c ROM), a new ROM could be developed which is, for all intents and purposes
as far as any program can tell, an Apple //e or //c ROM and should be able
to run on a Laser 128 even those programs which usually crash.

That said - it's a matter of implementation, of course: it would need to
be tweaked to get around those hardware (ROM-banking) differences. And
I'm not really sure what-all those differences actually are.

I'd try to do even more if I were sure it wouldn't break other stuff (such
as the ProDOS-8 clone check)...

-uso.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.sys.apple2

Several years ago I was dinking with a Laser 128, and later with the SimSystem IIe emulator which had a similar - it seems, string-hacked - firmware. I got to thinking about the occasional programs I'd try with
the 128 or SimSystem IIe that would blow up.

I think you meant "tinkering", "dinking" is such a harsh word. :)

Sometimes, these were old file-cracked single-load games, which I was able to get to work by using the old System Master to load an Apple ][ ROM, and then run them. That didn't always work.

I don't think it is the ROM that is at fault. More likely the use of illegal opcodes which the IIe tries to execute.

From what I understand, the hardware isn't quite enough like the Apple //e or //c, that a //e or //c ROM could be used unmodified to drive a Laser,
or a Laser ROM to drive a //e or //c - but I suspect there isn't much difference. I came up with the idea that perhaps, since most if not all
of the source to the parts of at least some versions of the //e and //c firmwares DO have the source published (excluding FPBASIC, which isn't really relevant to this apart of having to be brought in from a //e or //c ROM), a new ROM could be developed which is, for all intents and purposes
as far as any program can tell, an Apple //e or //c ROM and should be able to run on a Laser 128 even those programs which usually crash.

Maybe I can save you some trouble. The biggest reason it cannot work (Laser ROM in a IIe/IIc) is the firmware calls. The Laser has a third layer of firmware. From what I can tell, it engages a softswitch that switches in a 2nd layer of firmware under the $C100.C7FF range apart from the regular firmware. This won't work on a IIe/IIc.
For the most part, the IIe/IIc ROM's should work in a Laser 128.

That said - it's a matter of implementation, of course: it would need to
be tweaked to get around those hardware (ROM-banking) differences. And
I'm not really sure what-all those differences actually are.

It has been awhile so I am trying to remember off the top of my head. But what the Laser does is to one of the listings, either monitor listing or applesoft listing, was to look up the keywords from the $C300 or $C800 firmware. This won't work on a IIe/IIc.
But I don't see why a IIe ROM won't work in a Laser 128.

I'd try to do even more if I were sure it wouldn't break other stuff (such
as the ProDOS-8 clone check)...

I believe there is a program on the Franklin boot disk that shows how to defeat the Prodos clone check.
I thought I was going to get this big speed boost with the Laser ROM in a IIe. At last, I gave up on it, thinking it was more trouble than it was worth.
The results I came up with is, I believe the IIe firmware is faster in the IIe/IIc in some ways due to the constant softswitch flipping into the firmware the Laser does, but the Laser may make up for it as it uses more look-up tables and does fewer calculations, but the IIe/IIc does not have the extra memory for look-up tables.
Disassembling the Laser ROM did give me some insight to as why they were not subject to Apple's lawsuits, though. I recommend disassembling it for the curiousity, if not anything else.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.sys.apple2

On Tue, 23 Jan 2024, I am Rob wrote:

Several years ago I was dinking with a Laser 128, and later with the
SimSystem IIe emulator which had a similar - it seems, string-hacked -
firmware. I got to thinking about the occasional programs I'd try with
the 128 or SimSystem IIe that would blow up.

I think you meant "tinkering", "dinking" is such a harsh word. :)

I tend to be very dysphemistic when I talk about myself.

Sometimes, these were old file-cracked single-load games, which I was able >> to get to work by using the old System Master to load an Apple ][ ROM, and >> then run them. That didn't always work.

I don't think it is the ROM that is at fault. More likely the use of illegal opcodes which the IIe tries to execute.

If it worked on a 65SC02-based //e, then it most likely wasn't an ILLOP problem.

An example of a game that works on the Laser 128 if run from 50-sector INTBASIC is Cu-bit.

Maybe I can save you some trouble. The biggest reason it cannot work
(Laser ROM in a IIe/IIc) is the firmware calls. The Laser has a third
layer of firmware. From what I can tell, it engages a softswitch that switches in a 2nd layer of firmware under the $C100.C7FF range apart
from the regular firmware. This won't work on a IIe/IIc.

The //c does the same thing in a different way for the same reason (32K firmware in 16K of space).

For the most part, the IIe/IIc ROM's should work in a Laser 128.

That said - it's a matter of implementation, of course: it would need to
be tweaked to get around those hardware (ROM-banking) differences. And
I'm not really sure what-all those differences actually are.

It has been awhile so I am trying to remember off the top of my head.
But what the Laser does is to one of the listings, either monitor
listing or applesoft listing, was to look up the keywords from the $C300
or $C800 firmware. This won't work on a IIe/IIc.

Prolly the monitor, though iirc pieces of BASIC are located in the Cx
space too.

But I don't see why a IIe ROM won't work in a Laser 128.

The "ROM 255" //c may have a better chance of working since it doesn't
need to bank; there's just 16K ROM, full stop, rather than the 32K of
other models.

I know the //e has the diagnostic code at C600.

I'd try to do even more if I were sure it wouldn't break other stuff (such
as the ProDOS-8 clone check)...

I believe there is a program on the Franklin boot disk that shows how to defeat the Prodos clone check.

Workarounds are known.

<snip>

Disassembling the Laser ROM did give me some insight to as why they were
not subject to Apple's lawsuits, though. I recommend disassembling it
for the curiousity, if not anything else.

It's definitely different code.

-uso.
--- Synchronet 3.20a-Linux NewsLink 1.114