Smartbasic 2 EOS6? 7?, Here you go

[Captain Cozmos]

In the interest of science and I do not know if this is floating around...

I extracted the EOS from Smart Basic 2 which is supposed to be updated and fixed for bugs.

Is this what is referred as EOS6, EOS7?

I don't know fully and maybe someone already did this but it works with COLEM as far as I have tested it.

Either way, test, play with just please give me credit if I am the first.

 

CC
 

EOS.zip

[NIAD]

It is EOS7 and was first included on Disk Manager which was a pack-in with the Disk Drive. Including EOS7 with other software titles was a much easier way to get the upgraded OS into the hands of people than offering a system upgrade thru Honeywell to replace the prom. I think the only other program that I tested using EOS7 was SmartBasic 1.0 using the RUN FILE option in Disk Manager.

 

Rich Drushel (Dr. D) was the only other person that I recall doing any kind of investigative work and disassembly of EOS7.

  

[Captain Cozmos]

12 hours ago, NIAD said:

It is EOS7 and was first included on Disk Manager which was a pack-in with the Disk Drive. Including EOS7 with other software titles was a much easier way to get the upgraded OS into the hands of people than offering a system upgrade thru Honeywell to replace the prom. I think the only other program that I tested using EOS7 was SmartBasic 1.0 using the RUN FILE option in Disk Manager.

 

Rich Drushel (Dr. D) was the only other person that I recall doing any kind of investigative work and disassembly of EOS7.

  

Thanks for the info.

I will check again but for some reason it did not match up with the ADAM disk manager version.  DM was the first version I extracted.

However, I disassembled DM and SB2.  They are very interesting reads but nothing new under the sun.
 

SB2 resides in the upper half of expansion ram if you have it, normal ram if you don't.  It loads the new EOS7 in place blah blah blah..
I suspect if I tried hard enough I could recompile it to bank in larger ram modules but that would be a project for some other day.

Disk Manager is the basic of the basic in terms of what it does.

I brought the whole matter up because COLEM was using the older version, same as MAME and the other emulators, it was not in the archive so here you go.
If you do put it in the archive I would like some type of credit showing that it was extracted and put into the community because if everyone knew about it then where was it?

I went through the archive EOS section for ADAM and it was not there so I would expect to get credit for extracting and presenting it.  Same as the two books I gave everyone.

Edited December 28, 2022 by Captain Cozmos

[NIAD]

Very probable that the EOS7 from SmartBASIC 2.0 is a later revision seeing as that software package was still in development late into 1984 while Disk Manager was released with the disk drive in early 1984.

 

What I remember of EOS7 was mainly bug fixes and improved file handling.

 

Have you disassembled SB2? I ask because what you state doesn't seem accurate about "SB2 resides in the upper half of expansion RAM if you have it" seeing as if it did, one would expect to have upwards of 58K free space available in standard RAM versus the 26K that is actually available? It was unfinished, so perhaps this is the case and the programmers never got around to configuring the rest of the free space. If you are correct, that would explain the disk access (SB2 has to be placed in standard memory) when you use the EXTMEM command to access 64K of expansion RAM to have 90K of free space for programs.

 

All the emulators use EOS5 not only because that was the only EOS available, but for compatibility with software seeing as EOS7 will cause issues with numerous 3rd party programs.

 

Thanks for the contribution as this one was lost to the sans of time when Rich Drushel's website went down.

 

[Captain Cozmos]

1 hour ago, NIAD said:

Very probable that the EOS7 from SmartBASIC 2.0 is a later revision seeing as that software package was still in development late into 1984 while Disk Manager was released with the disk drive in early 1984.

 

What I remember of EOS7 was mainly bug fixes and improved file handling.

 

Have you disassembled SB2? I ask because what you state doesn't seem accurate about "SB2 resides in the upper half of expansion RAM if you have it" seeing as if it did, one would expect to have upwards of 58K free space available in standard RAM versus the 26K that is actually available? It was unfinished, so perhaps this is the case and the programmers never got around to configuring the rest of the free space. If you are correct, that would explain the disk access (SB2 has to be placed in standard memory) when you use the EXTMEM command to access 64K of expansion RAM to have 90K of free space for programs.

 

All the emulators use EOS5 not only because that was the only EOS available, but for compatibility with software seeing as EOS7 will cause issues with numerous 3rd party programs.

 

Thanks for the contribution as this one was lost to the sans of time when Rich Drushel's website went down.

 

I haven't studied the disassembly as much as I would like to.
I noticed early on in the boot block that it behaves differently when expansion ram is present.
It took me a while to extract the EOS because I was trying to grab an exact copy off of the disk before it was loaded and the numbers were fugged.
First off, it's not loading a block.  It opens Smartbasic as a file then loads it.  This makes sense because read a block does not check what is actually in the block like a super game.

 

Read one block can load in all zero's or a picture of your mom, it does not care.  If you use open file then at least it's trying to open an existing file.  If it can not open the file then it exits back to Smart Writer.  But, it does not check the directory on block 1. It checks right before the repeating Hi Cathy.

 

I may be reading all of this wrong but when you use the EXTMEM routine it checks for the flag set earlier then reloads everything into expansion ram if true
I don't remember the response if the flag is false but if extra ram is not present then EXTMEM should just kick you back to prompt.

Here is the boot code loaded into $C800

$C800                 ld   sp, $CBFE       ; set up the stack
$C803                 ld   c, b                ; set the device boot from
$C804                 ld   a, 2                ; expansion memory
$C806                 out (7Fh), a         ; load in expansion ram to test values
$C808                 ld    hl, 66h
$C80B                 ld    de, 200h
$C80E                 ld    b, 8

$C810                 ld    a, (hl)
$C811                 cpl
$C812                 ld    (hl), a
$C813                 cp   (hl)
$C814                 jr    nz, $C823      ;maybe? No expansion ram, just load SB2
$C816                 cpl
$C817                 ld    (hl), a
$C818                 cp   (hl)
$C819                 jr    nz, $C823      ; maybe? No expansion ram, just load SB2
$C81B                 add hl, de
$C81C                 djnz $C810

$C81E                 ld     a, 0FFh
$C820                 ld     ($C85E), a    ; I suspect this is to say that there is expansion ram and set this address for the EXTMEM or C814 or C819 maybe the on switch.

 

$C823                 ld     a, 1              ; Normal memory setup (default)
$C825                 out   (7Fh), a
$C827                 ld     a, c
$C828                 ld     b, 1
$C82A                 ld     hl, $C854
$C82D                 call   OPEN_FILE   ; (BASICPGM)
$C830                 jp     nz, GOTO_WP  ; (Failed to open) return to Smart Writer
$C833                 push af
$C834                 ld     bc, 8227h        ; load in 33,319 bytes or basically 32 blocks.
$C837                 ld     hl, 0
$C83A                 call   READ_FILE
$C83D                 pop  bc
$C83E                 jr     nz, $C84D
$C840                 ld     a, b
$C841                 call   CLOSE_FILE
$C844                 ld     a, ($C85E)
$C847                 ld     ($4196), a
$C84A                 jp     100h
 

 

What I believe could be happening is once SB2 is started that EOS7 is loaded in but I can not be certain till I go over the disassembly.
If you noticed the push AF and POP BC later that is a quick way of bypassing LD...ect....  It basically returns the previous values into the register below it because the stack is way faster than the rest of the Z80 command set.  It's a trick used a lot in moving graphics around.

Edited December 29, 2022 by Captain Cozmos

[Captain Cozmos]

Edited, then re edited, then re edited again.

 

 

Now that I read the boot block a bit more this is what I am thinking because I can not edit the last post.
It checks for expansion RAM.  It does not find it with one of the two checks it proceeds to load it.
If it find it, it loads $C85E with the value of $FF then loads in SB2 starting at block 0.
It then transfers the value at $C85E be it 255 or the original value into $4196
It then starts SP2 with a jump to 100H

When you use EXTMEM it will check for 255 at area $4196 and if it is present it will reload SB2 at $8000.
This is honestly the only way your going to switch expansion memory in or out because you can not have the main program in another bank or you will lose it.
So all your subroutines, BIOS, stack and pointers have to stay in the upper bank while at the same time switching out the lower bank as needed.

Edited December 29, 2022 by Captain Cozmos

[Captain Cozmos]

OK, confirmed with my equipment.

If it does not find expansion ram then it boots as stock and EXTMEM will just return to prompt.
If it does find it then it will load $FF into $C85E

 

But, what I am finding is that SB2 might actually remain in the lower half so I have to disassemble the program to see how it's doing this.
This is going against what I know on the root level as to how banking works.
Or, maybe my tests are just telling me the addresses are what that computer knows them to be until the bank is switched in.
No matter what I do the Z80 is always going to return a value between $0000 and $FFFF and my debugger says that SB2 resides at the very beginning of the lower half of the ram and the BIOS is up loaded in above $E000

 

 

A quick check and found that it does load everything in starting at $00 then starts at $100 which is 256.  Somewhere along the line it transfers the BIOS to $E000

Now, SB2 is also on the disk in two places.  One before and one after the BIOS.  So to get around the bank I would gather that it loads in the second version of SB2 then banks it in.

On a disk drive this would be no problem but if loading from DDP it would have to reload from block 2 then change the location of the BIOS to $E000
Now I am seeing is that if it loads the BIOS first then bank in expansion ram then the repeat of SB2 at $0 you get the same result but with the expansion ram in place.  It's a juggling act that works in the Z80 world but it seems to be the best idea for a system relying on data packs and hardware of the time.

I can check the ports or fill the memory with a large program but until then I really have other work to do so I will end it here.

CC

 

Edited December 29, 2022 by Captain Cozmos

[Captain Cozmos]

This not being able to edit crap has to be worked on.

My new findings are that in order to save rewinding back to block 2 on a data drive that EXTMEM banks the memory then loads SB2 from where the DDP stopped which was at the end of the BIOS on the disk or data pack.

From what I gather, the whole program is actually a little over 20k with an 8k updated EOS.  Just SB2 is repeated on the media.  I could be wrong and it may have to do with the banking.  I have to investigate further to be 100% but that should be the most likely scenario.

Again, I have lots of other work to do but now I'm curious on how the thing works.

Edited December 29, 2022 by Captain Cozmos

[Captain Cozmos]

Spending some time disassembling EOS7
You can follow along with official documentation for stock EOS but a lot of the routines have been moved around.  Of course, jump tables are intact.

I have now discovered a ton of programing techniques.  Paddles, Spinners, Super controllers, the reasons for why certain functions still exist.
I also discovered some very interesting code that I think will help me resolve the missing smurf data pointers.

Hopefully in the future I can create a 100% transportable disassembly of these games to where you can change anything and recompile.

In any case, I wanted to know the inner details of accessing the various drives and you would be surprised how simple everything is.

As far as my DOS project, I wrote my first command which is CLS or clear screen.  No issues.
Now I am working on DIR for the directories and FORMAT.

Has anyone used the greaseweazle Floppy Drive to USB?
This will keep me from looking for a PCI to floppy interface if it works well enough.
As long as it can write ADAM Disk images with no issues that would help cut down on development time.

 

For now I want to get as much working as possible before switching devices to be loaded as external drivers.

 

CC

[+mytek]

On 12/28/2022 at 11:39 PM, Captain Cozmos said:

This not being able to edit crap has to be worked on.

For a very reasonable (as in small) donation you can become a subscribed user and thus be able to edit your posts for up to 30 days. Also even without this option, you can make a request of Albert to be able to edit one particular page forever (e.g., the title page of the topic).

 

Hope that helps

[Captain Cozmos]

6 hours ago, mytek said:

For a very reasonable (as in small) donation you can become a subscribed user and thus be able to edit your posts for up to 30 days. Also even without this option, you can make a request of Albert to be able to edit one particular page forever (e.g., the title page of the topic).

 

Hope that helps

Thanks for the heads up.
My thinking is nobody wants to read all my mistakes.
BTW, how much to use spellcheck ...LOL🤣