Geneve OS development discussion

[+InsaneMultitasker]

Reposting some info that was in GDM2K topic, as it is more germane to OS dev. 

———————

 

@dhe and @Shift838 

You can hold the DEL key when the OS starts to force autoexec to load from Dsk1.  If this no longer works in the unmodified release and/or the CYA patched OS, then we need to fix that feature. 
 

With the EPROM and an unmodified OS, the autoexec will load from the boot device.  This is controlled by a flag in the loader (load-ide, for example) and a bit of code in the OS.  
 

With PFM, the autoexec location is typically set via CYA.  I suppose that I could code the PFM to set a boot flag, similar to the EPROM, as an alternative.  
 

CYA overrides the default location, to ensure the OS always loads autoexec from the same location during a warm restart.  Thinking about this now, what probably should be done is to save the boot flag and then use that device/location for subsequent warm reboots initiated by ctrl-alt-del

[+InsaneMultitasker]

I was looking through some old emails and found a bit of inspiration from our departed friend @Gazoo.   

 

One of Tony's methods for tackling tamper-resistant code was to disassemble the program into data statements, append his own routines, patch, and reassemble everything into a new program.   The ASM, MAKE, and LINK programs employ multiple protection schemes and are large, complex programs.  Overall, a good fit for Tony's approach.   The attached ZIP contains:

 

1.  LINKW - GenLINK 1.03, patched with GenWIPE v1.1 routines.

2.  WIPE - the standalone program. 

3.  Source code and linker files.

LINKW 6-23-2024 with source.zip

[+InsaneMultitasker]

The attached ZIP file contains EXEC v2.82 and the release documentation.  Two changes, precipitated by a MID error identified by @mizapf.

• Supports reset via "/4A ROM" address >0024 (RESET vector address).  Although not a preferred method, c99 returns to this address directly to return to the title screen (reset).  Previous versions of EXEC do not support this routine and as a result, generate MID errors in MAME and may cause system crashes.  Allows for a graceful exit by programs such as @F.G. Kaal's DSR loader.
• Modified EXEC's interrupt handler to test the mapper address at >8002. If the current page is >BA, a /4A-style interrupt detection is executed; if the current page is >07, the master DSR, control is passed to the OS to manage the interrupt.  The previous versions tested the ROMPAGE flag, however, if a program managed rompage operations on its own, the wrong interrupt routine could have been called. 

EXEC282.zip

[hloberg]

btw, there is a lot of old and outdated files on WHTECH that is mixed with newer stuff. anyway those old files might be moved into, say, an OLD folder to keep the confusion down for people look for good files for the Geneve?

[+Schmitzi]

4 hours ago, hloberg said:

btw, there is a lot of old and outdated files on WHTECH that is mixed with newer stuff. anyway those old files might be moved into, say, an OLD folder to keep the confusion down for people look for good files for the Geneve?

 

 

Not sure, but maybe files are existing there in these old and doubled folders,

where external hyperlinks (i.e. here from AA) were set to in the past,

and still are ponting to ? (and maybe to some folders themselve)

 

Means, deleting them would break those external links....

Maybe just delete files from inside such folders,

but leave the folders remaining there (empty) and add a link to the new location of the removed files  ?

 

 

[+mizapf]

The Geneve.new folder was my first attempt to bring some order into the system, but it was not finished. Maybe we should continue at that point.

[+dhe]

@9640News  with booting MDOS in CPU mode from TIPI seeming sorted, I have a question, does MDOS always use CPU Transfers when available?

[+InsaneMultitasker]

On 8/6/2024 at 12:03 PM, dhe said:

@9640News  with booting MDOS in CPU mode from TIPI seeming sorted, I have a question, does MDOS always use CPU Transfers when available?

MDOS internal IO is all DRAM/SRAM-based.  Programmers have the option to transfer data via VDP RAM but the typical approach is to use one or more memory pages or local task memory.  I started with VDP RAM transfers because I didn't grasp how to use the virtual pages for DRAM/SRAM transfers.   All told, the Geneve OS XOP-based DSR call makes file IO fairly easy.

[+InsaneMultitasker]

Two bugs as a result of floppy-device sector allocation review:

1. Large capacity floppy devices (larger than 3200 sectors / 800K) exhibit a cluster allocation problem.  Suspect 2009 change to GETAU. 

2. KILLing a non-existent file may cause ABASIC to freeze. Further testing required. After a few minutes, the interpreter responded again. 

3. (added 10/3) The hard drive bitmap allocation routine appears to wrap around to sector 0.  This is good except that the allocation routine should never try to allocate the reserved VIB or bitmap sectors.  File corruption that affects sector 1 could allow subsequent overwriting of the VIB (sector 0) with catastrophic results.  This is unlikely to be an issue.  

4. However.. item #3 is similar to a bug that -does- exist: a fractured file that exhausts all clusters in the parent FDIR will create a child FDIR.  The FDIR pointer in the parent or child may be reset to zero.  This results in the DSR using sector 0 in place of the FDIR sector, overwriting the VIB, and rendering the disk unusable. This seems to be more prevalent when the Sector:AU ratio is not 1:1.