Jump to content

Recommended Posts

I've been using some patched OS's for a while and they are working fine.  For example,  my 600XL and 130XE is using OS R4 as it's base.  The floating point package is running Fast Math v F and I fixed the self test table, for the banks, based on notes in the source code.  I've also been looking through the source code to figure out how to reverse the option key functionality.  While doing this, I was thinking that since the source code is available it would make more sense to just re-compile the source code with all the fixes as opposed to patching everything together with a hex editor.  Has anyone tried this?

 

I was thinking some improvements would be to start with OS v.4 and add the following:

 

Fast Math v F

Fix for the self test bank table.  

Space permitting, add self testing for additional banks.

Reverse the Option key.

Install the fast SIO in place of the international character set.  (Does anyone ever use the international character set?)

 

Of course, I don't know how many free bytes are still available to modify the OS.

 

I suppose that compiler directives could be used to make some of the changes optional....

 

Edited by reifsnyderb
  • Like 4
Link to comment
https://forums.atariage.com/topic/347696-compiling-a-new-atari-os/
Share on other sites

I've only compiled the 800 OS which I've modified for the GPB memory/IDE card, but there's plenty of source code around for the newer OS's.  I would imagine that people outside of English speaking countries make use of the international character set.  Space is in short supply, but there is the self-test area.  What does HiassofT's patch get rid of in the OS to make room for the high speed IO?  On the 400/800, it simply makes use of the unused C000-CFFF memory area, which is what I did for the GPB.

 

  • Thanks 1

@HiassofT 's patch replaces the international character set, from $CC00 to $CFFF, for the high speed SIO. 

 

What did you use to compile the 800 OS?  I've been thinking about trying to compile the XL/XE OS R. 4.

  • Like 1

Perhaps the international character set really isn't used much.

I don't think it matters much which assembler you use, just use whichever you feel most comfortable with.  I myself use xasm and sorted out an OS-B source file to get it to compile and have a matching binary to the stock ROM before making modifications.

https://github.com/pfusik/xasm/releases

be careful to allow an unrolled FP and the HISIO to occupy different parts of the international character set. might be an 8th order poly could take the place of a 10th as well, smaller faster and probably more accurate with later incantations...

@drac030 , @thorfdbg might be good to consult to give this a vulcan mind meld for a great /FP /math pack/ hsio/ party

Edited by _The Doctor__
8 minutes ago, _The Doctor__ said:

be careful to allow an unrolled FP and the HISIO to occupy different parts of the international character set. might be an 8th order poly could take the place of a 10th as well, smaller faster and probably more accurate with later incantations...

@drac030 , @thorfdbg might be good to consult to give this a vulcan mind meld for a great /FP /math pack/ hsio/ party

🤨

What does VFD mean?  It's not a 6502 instruction.  I am thinking it's some sort of compiler directive.

 

 

 

; Perform warmstart procedures.

 

PRS8 LDX #0

 

LDA DERRF ;screen OPEN error flag

BEQ PRS9 ;if in screen OPEN

 

; Clean up APPMHI.

 

; STX APPMHI

VFD 8\$8E,8\low APPMHI,8\high APPMHI

; STX APPMHI+1

VFD 8\$8E,8\low [APPMHI+1],8\high [APPMHI+1]

 

TXA

 

; Clear page 2 and part of page 3.

 

PRS9 STA $0200,X ;clear byte of page 2

 

CPX #low ACMVAR ;start of page 3 locations not to clear

BCS PRS10 ;if not to clear this page 3 location

 

STA $0300,X ;clear byte of page 3

I think a system to generate your own OS image with custom features would be handy.

Stuff like high speed SIO, different character set, reverse Option behaviour, no attract mode, different FP, alternate game ROM for XEGS etc etc.

 

But I would suggest rather than reassemble, a patch method might be better such that routines stay in place to remain compatible with programs that make illegal calls.

The XL OS has some unused space below $CC00 (varies, about 150 bytes) which would be sufficient for minor amendments.

13 minutes ago, Rybags said:

I think a system to generate your own OS image with custom features would be handy.

Stuff like high speed SIO, different character set, reverse Option behaviour, no attract mode, different FP, alternate game ROM for XEGS etc etc.

 

But I would suggest rather than reassemble, a patch method might be better such that routines stay in place to remain compatible with programs that make illegal calls.

The XL OS has some unused space below $CC00 (varies, about 150 bytes) which would be sufficient for minor amendments.

Were there still concerns about illegal calls as of the XL/XE OS?  I understand that illegal calls were used with OS/A and/or OS/B.  However, with all of the changes from the early OS's to the XL/XE OS's I figure that software developers would have used the vectors by then.

Probably not so much.  The lessons were learned mostly by 1984 though some insisted on continuing the behaviour.

If I was doing my own OS mods I'd probably go the patch route though.

In any case you might find things a bit tight in the $E000-$FFFF area - there seems to be about 30 bytes spare around $E49F and maybe a few just below the hardware vectors.

Pre XEGS Rom has free area from $CB65-$CBFF.

6 hours ago, reifsnyderb said:

While doing this, I was thinking that since the source code is available it would make more sense to just re-compile the source code with all the fixes as opposed to patching everything together with a hex editor.  Has anyone tried this?

I have prepared a package of sources of all OS versions in the format accepted by the ca65 cross-assembler.

3 hours ago, reifsnyderb said:

What does VFD mean?

It's just a directive to generate a sequence of bytes, similar to MAC/65's ".BYTE". They have used it as a way of forcing absolute addressing. "VFD 8\$8E,8\low APPMHI,8\high APPMHI" generates $8E, $0E, $00, which equals to "STX APPMHI" but using the absolute addressing instead of zero-page.

Edited by Kr0tki
  • Thanks 2

There are multiple alternative Os implementations "from scratch" which attempt similar things. Os++ of the Atari++ emulator works fine on native hardware, and features for example a faster math pack, and more graphic modes, plus multiple fixes. You can download the source from the atari++ project page. It builds with ca65.

  • Like 2
5 hours ago, Kr0tki said:

I have prepared a package of sources of all OS versions in the format accepted by the ca65 cross-assembler.

It's just a directive to generate a sequence of bytes, similar to MAC/65's ".BYTE". They have used it as a way of forcing absolute addressing. "VFD 8\$8E,8\low APPMHI,8\high APPMHI" generates $8E, $0E, $00, which equals to "STX APPMHI" but using the absolute addressing instead of zero-page.

Thanks!  I was using your sources with the wrong compiler.  I'll give it a try with the right compiler.

8 hours ago, Rybags said:

Probably not so much.  The lessons were learned mostly by 1984 though some insisted on continuing the behaviour.

If I was doing my own OS mods I'd probably go the patch route though.

In any case you might find things a bit tight in the $E000-$FFFF area - there seems to be about 30 bytes spare around $E49F and maybe a few just below the hardware vectors.

Pre XEGS Rom has free area from $CB65-$CBFF.

I was looking through the change logs and it looks like the XEGS ROM doesn't add much for an A8, such as an XL or XE.  Quite frankly, it looks like Atari forked the OS code at least 3 times.

11 hours ago, Panther said:

I've only compiled the 800 OS which I've modified for the GPB memory/IDE card, but there's plenty of source code around for the newer OS's.  I would imagine that people outside of English speaking countries make use of the international character set.  Space is in short supply, but there is the self-test area.  What does HiassofT's patch get rid of in the OS to make room for the high speed IO?  On the 400/800, it simply makes use of the unused C000-CFFF memory area, which is what I did for the GPB.

 

@Panther - Some French (and International) made programs are probably using the international character set. F.R.E.E. does use it. So it has its use at times.
 

free_1985_2.gif

While the international character set added a couple characters from various languages it was far from complete and it missed some important characters - IIRC Ä and ß for German language.

 

So word processors (eg StarTexter) and other programs in the german speaking area often used their own character set anyways.

 

so long,

 

Hias

  • Like 3

so using the other empty available spaces and such and using space made available by more efficient smaller math pack and the international charset might be spared or only the least used of the charset gets eaten. most programs provide their own tough...

 

*** edit Hias beat me to it.

Edited by _The Doctor__

Most german disk magazines did use the international charset with ÄÖÜ, äöü and ß. Reading these magazines with the standard charset (or with QMEG-OS and others) is not very good, since you get garbage or control-characters or whatever. The international charset is missing the german ß, but not the Ä afaik.

 

There are also several german A8 programs that make use of the int. charset, even commercial ones (text adventures, graphic adventures, RPG's, etc.).

https://a8.fandal.cz/detail.php?files_id=5657

https://a8.fandal.cz/detail.php?files_id=3816

https://a8.fandal.cz/detail.php?files_id=4034

https://a8.fandal.cz/detail.php?files_id=6818

https://a8.fandal.cz/detail.php?files_id=6112

https://a8.fandal.cz/detail.php?files_id=4204

 

And there are several programs that check the OS in a strange way to find out what OS version (or what computer) is present. There are some demos that only work with XL-OS Rev. 2 and not with others (think that is one of them:  https://a8.fandal.cz/detail.php?files_id=3679 but not sure). There are also several A8 tools / applications and games mentioned here at AA forum that only work with XL-Os Rev. 2 and not with others. Not all of these programs rely on the checksum of the OS however.

 

It stinks that some programs look at the checksums as they locked themselves into running on a particular version of the OS.

 

If I understand correctly, @HiassofT's fast SIO patch has to be done by patching the OS as there's no way to load it like a driver.  So, that is somewhat limiting.  If there were another way, I'd suggest putting it on a 1090 card.   🙂

 

I am also considering OS changes, and/or improvements, via a 1090 card.  For example, I've figured out a way to swap out the math pack on a 1090 card and just need to prove it.

 

It sounds like the international character set may have been used more than anticipated, too.

 

Since my main system is Windows based, I've been looking at compiling the OS from the command line.  Getting make to work on Windows is a problem.   😕   

OS v 2 stuff is already pretty much out the door as we have how many other official revisions in machines... so that's just programs that should have been or have been patched long ago.

new checksum generated isn't an issue. a program that relies on a certain checksum would need an update if it switches something for compatibility if it's just a check for checking sake then it should prolly be fixed on the software.

the char set issue was slightly addressed by a member pointing out places to stick stuff and sticking stuff where more room would be available after changes.

all thing being equal the Atari self test could always be abbreviated/modified/compacted/removed and a crap ton of stuff could go there... etc.

crazy last idea is if it requests international character set check the OS sets a flag and chuck high speed and loads the char set instead. etc etc.

many ways and choices to be had or made.

Edited by _The Doctor__
22 minutes ago, _The Doctor__ said:

OS v 2 stuff is already pretty much out the door as we have how many other official revisions in machines... so that's just programs that should have been or have been patched long ago.

new checksum generated isn't an issue. a program that relies on a certain checksum would need an update if it switches something for compatibility if it's just a check for checking sake then it should prolly be fixed on the software.

the char set issue was slightly addressed by a member pointing out places to stick stuff and sticking stuff where more room would be available after changes.

all thing being equal the Atari self test could always be abbreviated/modified/compacted/removed and a crap ton of stuff could go there... etc.

crazy last idea is if it requests international character set check the OS sets a flag and chuck high speed and loads the char set instead. etc etc.

many ways and choices to be had or made.

Throwing out the self test and installing high speed SIO in that location, as well as some other stuff, may be the best way to go.  @HiassofT:  Could this be done?

 

Having a flag for the international character set wouldn't work too well unless the ROM is loaded into RAM.  Given there are a lot of programs that use that RAM, I don't see how that would be practical.

the os already uses a tiny bit of ram to handle some of this and that, using a bit to indicate where to branch could be tricky but crazy ideas are always fun.

Self test revamp and shoving stuff there still sounds good as always.

Edited by _The Doctor__
1 hour ago, reifsnyderb said:

Throwing out the self test and installing high speed SIO in that location, as well as some other stuff, may be the best way to go.  @HiassofT:  Could this be done?

Not really. $5000-$57FF clashes with normal RAM, you'd have a hard time loading data via SIO to those RAM locations if ROM is mapped in, it might contain display or even worse DLI code/data that's being used or, very common, a RAM upgrade will decide to not map in ROM to that location as it uses PB7 for bank selection if PB4 is low.

 

You can reuse the selftest area, but not for things that are needed during normal operation.

 

Some patched OSes threw out cassette or PBI support to free up some space, but all of those are more commonly used than the international charset so aren't a good choice if you want to stay compatible with as many programs and setups as possible.

 

so long,

 

Hias

@HiassofT  Thanks!  Throwing out the international character set makes the most sense, then.

 

I just successfully compiled and tested, on Altirra, the XL R3 OS from @Kr0tki's sources.   🙂

 

Since I am running a Win 10 PC, I spent some time screwing around trying to get the makefile to work.  I wasn't successful installing make as I'd probably spend a whole day getting something like Cygwin to work.  I do have Linux running on a laptop but it would be rather inconvenient to use.  So, I decided I'd try to figure out how to compile the OS from the command line.

 

If anyone else wants to try, here's what worked for me:

 

You need @Kr0tki's sources he posted a link to earlier in this thread.

Also needed is the Windows version of cc65 (ld65.exe is included in the .zip file).

@HiassofT's patchrom can be used to add the checksum.

 

The source files required are:

bb1r3.s

camac.inc

xl.cfg

atarixl.cfg

 

You will need cc65.exe, ld65.exe, and patchrom.exe in the same directory.

 

The commands are:

 

ca65 -t atari bb1r3.s
ld65 -C xl.cfg bb1r3.o
patchrom -C a.out compiled.rom

 

The file compiled.rom is 16k and runs in Altirra.  I did a spot check, with a hex editor, and it appears identical to an already compiled ROM.  patchrom shows the checksums are identical, too.   🙂

 

I'll have to put those commands in a go.bat file, along with a copy command to install the ROM in the Altirra ROMs directory.

 

 

 

 

Edited by reifsnyderb
  • Like 3

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...