Distinguishing MOS 3.2 and MOS 3.5 in code?

Discuss all aspects of programming here. From 8-bit through to modern architectures.
SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby SteveF » Fri Jun 02, 2017 10:57 pm

Hi,

This seems like it should be easy, but I'm struggling!

INKEY-256 returns &FD (on b-em, but I don't think it's an emulation problem) and *FX0,1 returns 3 on both MOS 3.2 and 3.5.

Is there any other way to test this?

Cheers.

Steve

User avatar
jgharston
Posts: 2764
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby jgharston » Fri Jun 02, 2017 11:20 pm

The only way I've been able to do it is:

mos%=osbyte(0,255)*100
IF mos%=300 THEN
IF !&EED9='3.50' THEN mos%=350
ENDIF

But you should be checking for functionality, not implementation. Make the call, if nothing responds, the responder is not present. Eg, don't do IF machine=BBC THEN "No clock!", do IF OSWORD(14)=no_response THEN "No clock".

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby SteveF » Fri Jun 02, 2017 11:43 pm

Cheers. The problem I've actually been having is that (as pointed out by Elminster over in the STEM thread - viewtopic.php?f=2&t=10534), I have some code which tries to be helpful and offers to SRLOAD a ROM image and then auto-reset to initialise it by doing:

Code: Select all

*KEY0 *SRLOAD STEM 8000 ZQ|M*FX151,78,127|MCALL !-4!M
*FX21
*FX138,0,128

(I appreciate this isn't completely portable anyway - maybe the user has something they care about in bank Z, for a start - but it's mainly there for my convenience during development [1]. This is part of the test suite, not the actual end product for users.)

On OS 3.5, this hangs and even when you press CTRL-BREAK the ROM isn't loaded. So I was going to detect OS 3.5 and handle things differently.

Given your suggestion about checking for functionality, I was wondering if I could do something like:

Code: Select all

done%=TRUE
ON ERROR done%=FALSE
IF done% THEN *SRLOAD STEM 8000 ZQI       <-- note the 'I'
IF NOT done% THEN *SRLOAD STEM 8000 ZQ    <-- note no 'I'
IF NOT done% THEN OSCLI "FX151,78,127":CALL !-4

However, that's fine in a program, but I don't think I can use ON ERROR in immediate mode - which I need to be using if I'm going to use the 'Q' option on *SRLOAD.

(That is a very nice idiom, by the way!)

So my inclination is to use your MOS 3.5 test to decide which form to use, but if you have any suggestions on how else to do this I'd be interested!

[1] I like to run the test suite with the emulator at (say) 10x real speed, as it's very slow. So it's extremely handy for me to be able to load the latest build without needing to be able to type a *SRLOAD command manually, as the keyboard auto-repeat makes typing impossible on such high speeds and it's annoying to have to keep toggling the speed settings via the emulator menu. I just SHIFT-BREAK and this code offers to load the ROM, I press RETURN to confirm and then I can SHIFT-BREAK against and launch the tests.

User avatar
jgharston
Posts: 2764
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby jgharston » Sat Jun 03, 2017 9:21 pm

SteveF wrote:Cheers. The problem I've actually been having is that (as pointed out by Elminster over in the STEM thread - viewtopic.php?f=2&t=10534), I have some code which tries to be helpful and offers to SRLOAD a ROM image and then auto-reset to initialise it by doing:

Code: Select all

*KEY0 *SRLOAD STEM 8000 ZQ|M*FX151,78,127|MCALL !-4!M
*FX21
*FX138,0,128
...
On OS 3.5, this hangs and even when you press CTRL-BREAK the ROM isn't loaded. So I was going to detect OS 3.5 and handle things differently.

Odd, as far as I can remember the only change to the SRAM tools in MOS 3.50 is the addition of the 'I' option. *SRLOAD file ZQ should work on any Master MOS. Maybe it's the Z bank number, I've always used numberic bank numbers, viz *SRLOAD file 4. Maybe it's the absense of spaces after the bank number, I've always used for example *SRLOAD file 8000 4 Q.

SteveF wrote:Given your suggestion about checking for functionality, I was wondering if I could do something like:

Code: Select all

done%=TRUE
ON ERROR done%=FALSE
IF done% THEN *SRLOAD STEM 8000 ZQI       <-- note the 'I'
IF NOT done% THEN *SRLOAD STEM 8000 ZQ    <-- note no 'I'
IF NOT done% THEN OSCLI "FX151,78,127":CALL !-4

However, that's fine in a program, but I don't think I can use ON ERROR in immediate mode - which I need to be using if I'm going to use the 'Q' option on *SRLOAD.

To do it from immediate mode you can test ERR, something like:
ERROR:REM Ensure ERR set to known value, 'Mistake'
*SRLOAD STEM 8000 ZQI
IF ERR=254 THEN *SRLOAD STEM 8000 ZQ
IF ERR<>254 THEN OSCLI "FX151,78,127":CALL !-4

I've got a handful of EXEC files similar to the above, though typically I can't remember where they are or what they do. ;)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2764
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby jgharston » Sat Jun 03, 2017 9:25 pm

Bingo! I remember! In MOS 3.50 and MOS 5.xx a power-on reset (or simulated) explicitly wipes sideways RAM banks. So, yes, you are going to find that loading something into sideways RAM then doing a simulated power-on reset results in there being nothing there! I had to change the code in the HADFS boot code because of this, you'd boot a system disk to load HADFS into sideways RAM, it simulated a Break, and the freshly-loaded HADFS was no longer there.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby Elminster » Sat Jun 03, 2017 9:30 pm

This sounds like the GoSDC 'reload' ROM feature, used for the goSDC hacked ADFS/DFS filesystems loaded in bank 4,5,6 or 7 on Master.

EDIT: AH not quite. But sounded simialr.

Code: Select all

ROM0 through ROMF

ROM0 through ROM9 and ROMA through ROMF configure a 'plug' activity for ROM number 0 through 15 respectively.

ROMx    Plug activity
0    none
1    unplug ROM
2    re-insert ROM (1)
others    reserved

(1) Use this if the OS automatically 'unplugs' the ROM because it looks like an alias of another ROM (refer to 'Filing systems' for details).

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Distinguishing MOS 3.2 and MOS 3.5 in code?

Postby SteveF » Sun Jun 04, 2017 4:24 pm

Cheers, that works a treat!


Return to “programming”

Who is online

Users browsing this forum: No registered users and 1 guest