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.