bexec* autostart

[wawa.voun]

Hello there,

I use OS65D V3.3 Tutorial 5 as a working disk and I am wondering if there a way to autostart bexec* after boot.

Now the system (Junior Computer) boot and come to basic prompt.
A that point the system is more or less unusable because for example 'list' dont work.
If I manually start bexec* and then come back to basic prompt then 'list' works...

So is it possible to have a bexec* autostart after boot and how ?

Regards.
Philippe

pls note that a few bytes of OS6D has been modified accordingly to Elektor's instructions....

[Mark]

BEXEC* is the name of the default program run when booting OS65D. Any BASIC program can be saved as BEXEC* to be run automatically at boot.

By default OSI OS65D loads with LIST and NEW disabled, Control-C disabled, default Input set to "memory input" and default output set to NULL. I assume this was done to limit unauthorized users from messing with programs. You can enable "normal" behavior with a few line of code added to your own BEXEC*.

OSI OS65D3.3 tutorial disk #5 BEXEC* contains some code at lines 5-30, and 59000+ to enable normal BASIC, set memory size and enable I/O. The following lines have been extracted from there:

Code: Select all

10 POKE741,76:POKE750,78 : REM Enable LIST,NEW
20 POKE14172,8:POKE14170,16 : REM enable backspace
30 POKE8722,0 : REM NULL input if 0, normal if 27
40 POKE2893,55:POKE2894,8 : REM Enable Redo From Start, 
50 POKE2073,173 : REM Enable ^C
60 X=PEEK(10950):POKE 8993,X:POKE8994,X:REM Set default I/O devs
70 X=PEEK(8960):POKE133,X : REM Set Basic workspace hi mem addr

See OSI C4P operators manual pg. 87+ for memory locations used by BASIC.

Or you could patch the BASIC stored on floppy to enable these behaviors by default. I have located these locations on the OSI DOS 3.3 Tutorial disk 5 DUMP image. See below:

Code: Select all

OS65D3.3 Tutorial Disk 5
Hex offset of WinOSI raw disk dump (.65D) format
Offset $12EC on disk, mem = $02E5(741) : original = $0A, enable "list" = $4C 
Offset $12F5 on disk, mem =$02EE (750) : original = $0A, enable "new" = $4E
Offset $1C54 on disk, mem =$0B4D (2893): $37 was 1C ; redo from start msg on null input
Offset $1C55 on disk, mem =$0B4E (2894): $08 was 0B ;allow null input to exit program
Offset $1820 on disk, mem =$0819 (2073): enable ^C = $AD, disable = $60
Offset $0124 on disk, mem =$2321 (8993): input device was $10 (memory), make $02 to start keyboard at dos prompt, no bexec*, 01 for serial
Offset $0125 on disk, mem =$2322 (8994): default output device was $00 (null), make $02 to send output to video display, 01 for serial
Offset $79ED on disk, mem =$375a (14170): $10 was 00 ;enable true backspace
Offset $79EF on disk, mem =$375c (14172): $08 was 00 ;enable true backspace
Offset $0D30+ on disk specifies 6 character filename loaded at start if input device is "memory" ($10), default is "BEXEC*

If you change the default input device from "Memory" (16) Bexec* will not run automatically.
If you change the default output device to video (02) or serial (01) instead of NULL you will see the following message on boot (on a 40K system):

OS-65D V3.0
OSI 9 DIGIT BASIC
COPYRIGHT 1977 BY MICROSOFT
34177 BYTES FREE


Ok

I may have missed something, but I believe the information above is correct. Memory locations were determined using WINOSI and the OS65D C4P tutorial disk clean dump image.

I have included a patched OS65D Tutorial #5 disk image, which still retains the original BEXEC*, however if you replace or eliminate BEXEC* the system will still be open, ^C, LIST and NEW will work.
You need to add the BASIC line

Code: Select all

X=PEEK(10950):POKE 8993,X:POKE8994,X

to your own BEXEC* using the patched disk image below to set input to the default device (keyboard) in your BEXEC* replacement or you will get a few garbage characters on screen from the data after the BEXEC* name on the floppy disk.

Hope this helps,
-Mark

[tanteju]

Hi,

Actually exec* is in the input buffer and automatically executed after boot, even on Junior or EC65/Samson/Octopus65 (all of them I have). As Mark mentioned, it does some changes to the Basic to enable New and List and to the Memory. You could load disk sectors, do the changes and write them back to have a system boot w/o bexec* have the right settings. Actually those are just some pokes to memory locations.

[bxdanny]

OK, what are EC65, Samson, and Octopus65? I never knew there were so many third-party systems that could run OS-65D!

[wawa.voun]

Hello,

Thanks Mark and tanteju for your research and advices !

On my Junior system boot into basic but bexec* wont start at boot and I dont know why ???

I will check all memory locations mentionned by mark and see...

If anybody has a Tutorial 5 system disk for Junior Computer where bexec* start at boot I am very interested to get a hfe image.

Regards.
Philippe

[tanteju]

Hello,

Thanks Mark and tanteju for your research and advices !

On my Junior system boot into basic but bexec* wont start at boot and I dont know why ???

I will check all memory locations mentionned by mark and see...

If anybody has a Tutorial 5 system disk for Junior Computer where bexec* start at boot I am very interested to get a hfe image.

The trick with the autostart is, that the OS input buffer on disk (it is within track 01,1, if I remember correctly) already contains the RUN"BEXEC* string and size is appropriately set. Would need to check listing for the exact byte locations. Should be easy to fix. Load the sector in RAM, update the counter (which is most likely the reason) and write back.

During boot it will automatically load Basic and that's the first time Input Routine will be called. This then identifies already bytes in input buffer and act accordingly. That's the reason why BEXEC* will not be automatically started, when you start Basic from Kernel prompt.

I only have the EC65 disks, which has a different memory layout as the Junior. That would not help you.

OK, what are EC65, Samson, and Octopus65? I never knew there were so many third-party systems that could run OS-65D!

Junior was a kind of KIM-1 replica from Elektor electronics magazine. This SBC was then extended with memory cads and interface card and a video terminal (16*64) and then a floppy controller, which enabled it to run OS65D. There is a ROM routine on the interface cad, which patches an original OSI OS65D to work on the Junior.

Junior mainboard and Interface card were quite large and the hex keyboard and 6 digit display on the mainboard were not needed for OS65D anymore. Hence Elektor released the SAMSON 65, which was a CPU board in Eurocard format (100*160mm). This came in combo with a 6845 based VDU on a separate card. You could use the cards from Junior, e.g. the FDC or the 16/64K DRAM.

Due to name protection of "SAMSON" they then had to rename it and called it "EC65" (Eurocard Computer 6502) in Germany and maybe some other countries, while in NL it was called Octopus 65.

The system was enhanced with Basicode, real time clock, EPROM programmer, Z80 card to run CP/M on (the OS65D kernel was stripped in such a way, that it was just the I/O of the Z80 card, where CP/M was running on) and EC65K CPU card replacing the 6502 with 16 bit version, plus 256 K SRAM card. That was then the end of OS65 support, but I was not able to get a working copy of the 65816 operating system so far.

[tanteju]

Ok, I've checked the source listings. What you are looking for is on track 01,1.
Track 01,1 is loaded at $2a00. The input buffer is 18 bytes long and resides at $2e1e. It should look like this:

Bildschirmfoto 2021-07-13 um 23.49.05.png (208.2 KiB) Viewed 4840 times

Note, that there is CR ($0d) at beginning of the buffer (offset 0) and the RUN"BEXEC*" string starts at offset 7 and is terminated with CR.

The routine rating from the buffer is at $2ce4 and should initially look this way:

Bildschirmfoto 2021-07-13 um 23.48.39.png (661.71 KiB) Viewed 4840 times

The offset BUFOFS is at $2ce5. This is self modifying code. Initially there is a $07 as shown in the listing. When Basic queries for inout it would now start getting the command.

To get your disk autoload BEXEC* load track 01,1 into memory, e.g. "CA 4A00=01,1".
Now go into monitor and check if $4E1E match what is shown in the listing. If that is the case, then verify $4CE5. It's probably $00 and not $07. Change to $07 and go back to kernel. Save it back with "SA 01,1=4A00/8" and now it should autorun BEXEC* on startup.

[wawa.voun]

Again great thanks for the help.

I have check various memory locations :

After boot in $2321 I found $01 so the system looks to be set for serial input (which is understandable because he use a serial keyboard).

After loading track 1 to $4a00 I found $0e in $4ce5.

Then
$4ce6 $b1 $e1

$00e1 is $1e and $00e2 is $2e so the buffer begin address look to be the same ($2e1e)...

This mean that the string 'RUN BEXEC*' should start at $4e2c which is not the case.
More curious is that I did not find any trace of "BEX" ($42 $45 $58) string between $4a00 to $4ff...

The buffer routine looks different... I have
$4ce8 $4c $6a
$4cea $3a $ea

after that same as in previous post.

I use V3.3 for C1P. May be this explain the differences ?

Because I use a serial keyboard I am not sure that I can set $2321 to $10 (memory) instead of $01 ?

Regards.
Philippe

[Mark]

Can you make a .65D from your floppy image and post it? HFE would work too, it's just 10x+ larger with the same information more or less. It would be interesting to see the changes.

[wawa.voun]

This is the image I use :

OS65D_3.3_Tut5_VDU.65D.zip

(38.39 KiB) Downloaded 343 times

It has been made from an original C1P tutorial 5 image which has been patched two times :

** First for working with Junior and serial terminal, from original disk :
- track 0 is loaded to $2200 and track 1 to $2a00
- then following changes are made
$2217 4c 40 22
$2245 4c 76 22
$2285 8e c6 2a 4c b3 22
$2e84 4c b0 2e
- track 0 and 1 are re writed to disk and that's it!

** The second patch is for working with the so called VDU board :
- from the previous floppy track 0 is loaded to $a200
- then

VDU_patch.png (34.47 KiB) Viewed 4821 times

- track 0 is then rewrited to disk.

This image works well except they dont start bexec* at boot.
Also I noticed that after floppy copying (bexec* option 8) the program dont return to bexec* but return to hexadecimal keyboard + display and system has to be rebooted...
Both problems already appear after first patch.

Regards.
Philippe