Jump to content
jedimatt42

I need a new users guide to MDOS and the last 35 years

Recommended Posts

(Using a SNUG HRD17 ramdisk card, with 3MEG of storage)

 

So, with FORM3MEG if I pick the 8bit (256K) ramdisk option at crubase 1400, then the Geneve will boot SYSTEM/SYS from the ramdisk, and autoload AUTOEXEC from the ramdisk as well.

The 256K ramdisk shows up as DSK6. 

 

That AUTOEXEC can then be configured to do things like set PDMA ON pro-actively ( MDOS 6.70 seems to, as described, detect PDMA automatically upon first disk access ). Can setup any desired assigns. 

 

If I create the 16bit (800K) ramdisk option instead, then it doesn't seem to be boot-able - it tries, but then the Geneve is frozen at the loading screen. 

 

when in this state I have to hold the space-bar down to select and force booting from the floppy. 

 

with FORM123 the same scenario with the 8bit (256K) ramdisk format works. Loads AUTOEXEC from booted ramdisk.

 

However the 16bit (800k) option, boots, but it doesn't load the AUTOEXEC from the ramdisk.

 

The FAQ Beery posted speaks of the Phoenix Mod to HRD3000 boards as creating the smaller, well behaved bootable ramdisk partition, and then allowing the rest of the ramdisk to be utilized as a second, full size ramdisk. But it is unclear to me if full size meant 800k for the secondary. Sounds like the new HRD4000B all have Phoenix mod built in. 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Matt,

 

Likely, you have found it already, but if you haven't, check out 9640news.ddns.net:8080 .  I have on my website, the updated files for the GenProg package that details all the embedded operating system calls for programming under MDOS.  I know of no better reference.

 

Beery

  • Like 1

Share this post


Link to post
Share on other sites

The HRD16 is an 8-bit RAMdisk unless it has the appropriate cable and is connected to a SNUG SGCPU card. So, unless you have that configuration it should be formatted as 8 bits. 

Share this post


Link to post
Share on other sites
12 hours ago, jedimatt42 said:

(Using a SNUG HRD17 ramdisk card, with 3MEG of storage)

 

So, with FORM3MEG if I pick the 8bit (256K) ramdisk option at crubase 1400, then the Geneve will boot SYSTEM/SYS from the ramdisk, and autoload AUTOEXEC from the ramdisk as well.

The 256K ramdisk shows up as DSK6. 

 

That AUTOEXEC can then be configured to do things like set PDMA ON pro-actively ( MDOS 6.70 seems to, as described, detect PDMA automatically upon first disk access ). Can setup any desired assigns. 

 

If I create the 16bit (800K) ramdisk option instead, then it doesn't seem to be boot-able - it tries, but then the Geneve is frozen at the loading screen. 

 

when in this state I have to hold the space-bar down to select and force booting from the floppy. 

 

with FORM123 the same scenario with the 8bit (256K) ramdisk format works. Loads AUTOEXEC from booted ramdisk.

 

However the 16bit (800k) option, boots, but it doesn't load the AUTOEXEC from the ramdisk.

 

The FAQ Beery posted speaks of the Phoenix Mod to HRD3000 boards as creating the smaller, well behaved bootable ramdisk partition, and then allowing the rest of the ramdisk to be utilized as a second, full size ramdisk. But it is unclear to me if full size meant 800k for the secondary. Sounds like the new HRD4000B all have Phoenix mod built in. 

 

 

If you format the 16-bit option with Form123, install MDOS to the ramdisk, reboot, and then remap DSK6, can you catalog (DIR)  its contents?   If so, the remap default setting is the problem. Type "REMAP" at the command line to see the current mappings.

 

Your experience may be a good reason for me to issue an update to the 6.50 distribution to force MDOS to use the 16-bit ramdisks at 1400 and 1600 as default.  The 8-bit default was appropriate long ago when large ramdisks were not the norm.  It would require me to basically sector edit one or two bytes and recalculate the CRC validation table. This might be an option in lieu of the MDOS 7. release.  CYA is also an option for you in this case.

 

The Phoenix mod itself was deprecated long ago. The option to "split" the ramdisk into two drives may be an option if the hardware allows it, this would put one at 140x and the other at 160x.  I've not tested this since 1989 or 1990, when the ramdisk low level code was changed to what is currently in use.

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, InsaneMultitasker said:

If you format the 16-bit option with Form123, install MDOS to the ramdisk, reboot, and then remap DSK6, can you catalog (DIR)  its contents?   If so, the remap default setting is the problem. Type "REMAP" at the command line to see the current mappings.

 

Your experience may be a good reason for me to issue an update to the 6.50 distribution to force MDOS to use the 16-bit ramdisks at 1400 and 1600 as default.  The 8-bit default was appropriate long ago when large ramdisks were not the norm.  It would require me to basically sector edit one or two bytes and recalculate the CRC validation table. This might be an option in lieu of the MDOS 7. release.  CYA is also an option for you in this case.

 

The Phoenix mod itself was deprecated long ago. The option to "split" the ramdisk into two drives may be an option if the hardware allows it, this would put one at 140x and the other at 160x.  I've not tested this since 1989 or 1990, when the ramdisk low level code was changed to what is currently in use.

 

Yep with the 800k format, from FORM123, I can indeed boot SYSTEM/SYS from the ramdisk, after being dumped to the A prompt, I can ASSIGN E=DSK8: and I can 'dir' or write files fine... If I place an AUTOEXEC in E: it is ignored on next boot. I'm letting FORM123 copy the SYSTEM/SYS, and answer YES to the questions about formatting for MDOS boot. 

 

The general public doesn't know about the MDOS 7 release... 

 

Previous rounds of questioning, yielded the advice that I run MDOS 6.70 for the sake of the SCSI controller performance. 

 

If 256K is the state of things on an HRD17 without editing files... that's a good successful state.

 

---

 

I haven't had success with CYA... it tends to cause a VDP DRAM pattern table melt-down... It seems fine until I go to save, or edit assign statements...  The only version of CYA I find is on the MDOS 6.50 distribution. CONFIG-YOUR-AUTOEXEC v6.50 [13 Oct, 2002] ... (I'm running MDOS 6.70) 

I can go through and change the 'Batch' section, path to load AUTOEXEC, to DSK8.AUTOEXEC, but then when I attempt to 'save' it says Loading SYSTEM/SYS and locks up.. At the moment, I don't have a DSK8.AUTOEXEC cause I've restored to the working DSK6. 256K ramdisk configuration.   

 

When I get more time this weekend, I can try this whole experience again with MDOS 6.50 ---  

 

Share this post


Link to post
Share on other sites
12 hours ago, atrax27407 said:

The HRD16 is an 8-bit RAMdisk unless it has the appropriate cable and is connected to a SNUG SGCPU card. So, unless you have that configuration it should be formatted as 8 bits. 

 

Do we know what the difference is between an HRD16 and an HRD17? The sticker on the CPLD says "HRD17 v1.0 15.10.98", and the nearby PAL is labelled "HRD_PAL2 V1.0"

Share this post


Link to post
Share on other sites

CYA does not know how to properly update MDOS versions beyond 6.50.  From the 6.70RC2 release notes,  near the end of the file :

 

"A CRC has been encoded in this release; however, please note that CYA is not yet reconfigured to use this new MDOS. You will find it necessary to revert to an AUTOEXEC or command line commands."

 

I suppose the lockup could be caused by CYA traversing the linked lists and setting up MDOS with the new parameters.  Is your VDP DRAM still suspect?  CYA does heavily use VDP for screen overlays.

 

The 6.70x releases were intended to solicit feedback and test stability.  There was relatively minimal response to the two release candidates.

 

Based on your results, the remap setting appears to be the one barrier to executing the AUTOEXEC file from the ramdisk.

 

If you wish to use 6.70RC2,  execute your autoexec from the command line using the ampersand*, e.g., "&DSK6.AUTOEXEC"   This is how I am currently handling my system (for different reasons than you)  though to save my fingers I renamed it "T" and execute as "&DSK6.T".

 

(*The ampersand performs a warm restart and will execute a batch file.)

 

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

VDP overlays, that would make sense. Like going to the assign screen, probably moves the vdp name table to an address on a bad chip. I think from there, I was able to escape until I got back to mdos, at which point the screen was fine. 

 

I'll write a memory tester for 128k of VDP RAM. 

Share this post


Link to post
Share on other sites

Redoing my setup with MDOS 6.50, I have the same issue with the 800K ramdisk setup. It refuses to execute an AUTOEXEC.. (until later where I figure out how to fix it... more below)

I placed an AUTOEXEC on the floppy, that issues 'TIMODE'

One on the ramdisk, that echos HRD

and one on the SCSI drive that echos SCSI

 

None run... 

 

I've used CYA to assign B=DSK8, C=SCS1, set autoexec path to DSK8.AUTOEXEC  ( also tried SCS1.AUTOEXEC ).  The REMAP settings look fine, the HRD is defaulting into DSK8.

 

However, apparently when booting off the HRD, if you want an autoexec to run, you MUST map DSK6 to the  HRD you are booting from, and then the autoexec path should be DSK6.AUTOEXEC.   

I'm guessing the HRD boot process is forcing the AUTOEXEC path to be DSK6.AUTOEXEC, and it doesn't matter what you put in the AUTOEXEC path from CYA... 

 

So, success, 800K HRD17 Boot... 

 

Final non-defaults in CYA:

assigns: B) DSK6, C) SCS1, ( only have one floppy on this box, and I don't really want to use it, except if I have to fix things, transfer files (gotek) ) 

remap: DSK6 - 16-bit RAM @>1400  ( quoting CYA ), DSK8 - 8-bit RAM @>1400

 

Also, the VDP RAM issue... well CYA on MDOS 6.50 worked fine... all the screens that go NUTs when I was poking at 6.70 do not corrupt my screen when using it properly as described with ONLY 6.50 :)  I'll still write a VDP memtest... somewhere I have a gcc/mdos build process that interfaces the XOPs ... and it will be nice to stop my FUD... 

 

Ooh, now to backup my SYSTEM/SYS before I lose it... 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

Also, retesting MDOS 6.50 and FORM3MEG vs FORM123 : 

 

FORM3MEG's 800k large format with the HRD17 does not boot.. just locks up. 

FORM123 800k or 256k format work fine with this card. 

FORM3MEG's 256k format works fine with this card. 

 

Genmod Geneve boot ROM 1.0

Edited by jedimatt42
InsaneMultitasker educated me to the fact that FORM3MEG tries to do the full capacity if not requesting the 256k mode.

Share this post


Link to post
Share on other sites

Guessing FORM3MEG lockup is due to the FDR/allocation unit issue. Found this note in my 2013 email.  I believe it will address the problem, however, there are problems with file allocations beyond 800k.  (insert tired mantra re: MDOS 7.00 fixes in theory already address this issue).  The DSK6. statement seems to corroborate your findings regarding autoexec. 

 

> > Start by using FORM3MEG to format it.
> >
> > If you want to boot from it, the best bet is to set it at CRU >1400,
> > and configure it as DSK6 in MDOS. That way it will pick up the
> > AUTOEXEC file from the ramdisk.
> >
> > If the ramdisk is over 800k and you want to boot from it, read
> > the excellent article on the procedure in the final issue of
> > Micropendium. :)
> >
> > Tony
> >

  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks for this thread. I am trying to boot from HRD3000 as well, but also do not understand how to map format it yet and load everything feom HRD

Share this post


Link to post
Share on other sites
Posted (edited)
5 hours ago, globeron said:

Thanks for this thread. I am trying to boot from HRD3000 as well, but also do not understand how to map format it yet and load everything feom HRD

I'm working on an illustrated  detailed step by step write up today. 

Edited by jedimatt42
pictures are beyond me in media-wiki right now

Share this post


Link to post
Share on other sites
21 hours ago, InsaneMultitasker said:

Guessing FORM3MEG lockup is due to the FDR/allocation unit issue. Found this note in my 2013 email.  I believe it will address the problem, however, there are problems with file allocations beyond 800k.  (insert tired mantra re: MDOS 7.00 fixes in theory already address this issue).  The DSK6. statement seems to corroborate your findings regarding autoexec. 

 

> > Start by using FORM3MEG to format it.
> >
> > If you want to boot from it, the best bet is to set it at CRU >1400,
> > and configure it as DSK6 in MDOS. That way it will pick up the
> > AUTOEXEC file from the ramdisk.
> >
> > If the ramdisk is over 800k and you want to boot from it, read
> > the excellent article on the procedure in the final issue of
> > Micropendium. :)
> >
> > Tony
> >

 

So, what was the 'final issue of Micropendium' that this refers to? The previous issue at the time of this note, or the actual last issue... and What was the actual last issue - the info on http://ftp.whtech.com/magazines/micropendium doesn't describe the repository's completeness. 

 

 

Share this post


Link to post
Share on other sites
8 hours ago, jedimatt42 said:

 

So, what was the 'final issue of Micropendium' that this refers to? The previous issue at the time of this note, or the actual last issue... and What was the actual last issue - the info on http://ftp.whtech.com/magazines/micropendium doesn't describe the repository's completeness. 

 

 

Final as in "no more Micropendium published after this point".  I located the issue, filename "mp99last".  Why it isn't named in sequence with the others from the same year is beyond me - someone with access to WHT should rename and fix this, IMHO.

 

See pages 2-3 and 25.

https://ftp.whtech.com/magazines/micropendium/mp99last.pdf

 

 

  • Haha 1

Share this post


Link to post
Share on other sites
14 minutes ago, InsaneMultitasker said:

Final as in "no more Micripendium published after this point".  I located the issue, filename "mp99last".  Why it isn't named in sequence with the others from the same year is beyond me - someone with access to WHT should rename and fix this, IMHO.

 

See pages 2-3 and 25.

https://ftp.whtech.com/magazines/micropendium/mp99last.pdf

 

 

 

Thanks, most of the organization in whtech is 'beyond me'. 

Share this post


Link to post
Share on other sites

CYA for Geneve 9640.pdf  [renamed]

 

Here's a version of the CYA manual that predates the 6.50 release.  I need to locate my old file backups to see if I have a later version.  I wrote the original documentation using WordPerfect.  Tony and I had collaborated to update CYA and MDOS back in 2001/2002, so there should be a newer manual.  I'll add it to my list of followup items

 

Edit: Maybe I knew more in 1994 than I do today. ;) 

 

image.thumb.png.5ff305ca09e8c63df5166153e53d315f.png.

  • Like 2

Share this post


Link to post
Share on other sites

 

23 hours ago, InsaneMultitasker said:

Guessing FORM3MEG lockup is due to the FDR/allocation unit issue. Found this note in my 2013 email.  I believe it will address the problem, however, there are problems with file allocations beyond 800k.  (insert tired mantra re: MDOS 7.00 fixes in theory already address this issue).  The DSK6. statement seems to corroborate your findings regarding autoexec. 

 

> > Start by using FORM3MEG to format it.
> >
> > If you want to boot from it, the best bet is to set it at CRU >1400,
> > and configure it as DSK6 in MDOS. That way it will pick up the
> > AUTOEXEC file from the ramdisk.
> >
> > If the ramdisk is over 800k and you want to boot from it, read
> > the excellent article on the procedure in the final issue of
> > Micropendium. :)
> >
> > Tony
> >

 

So, I'm assuming the title of the article is misleading... "How to make a bootable 800K Horizon Ramdisk" - you get a bootable 800k ramdisk with FORM123... 

 

Tony's procedure will produce a full sized ramdisk, with FORM3MEG. I believe you must also have previously edited the mappings embedded in the source SYSTEM/SYS so the 16-bit ramdisk at >1400 device is designated DSK6, before letting FORM3MEG copy it. Otherwise it would still fail to look for the AUTOEXEC correctly.  And once you've run Tony's procedure to hack up the FDR, you can't use CYA to edit that SYSTEM"/"SYS again... 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

With thanks and appreciation to @jedimatt42, attached is a slightly modified version of MDOS / Geneve OS 6.50. 

 

The only OS change is that the default DSKx mappings (via REMAP) have been modified and a new CRC applied. 

 

DSK6. and DSK7. are now configured as "16-bit" ramdisks.   I also quickly tweaked some documentation, replaced CRACK128 with CRCOS, added FORM v1.23, modified the CYA title screen, and removed the (old) version of DU2K. 

 

GeneveOpSys650-redistributionpermitted2020.dsk

 

If someone could please add this image to WHT that would be appreciated.  The prior release may be archived or deleted, IMHO.  

 

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites
3 hours ago, InsaneMultitasker said:

With thanks and appreciation to @jedimatt42, attached is a slightly modified version of MDOS / Geneve OS 6.50. 

 

The only OS change is that the default DSKx mappings (via REMAP) have been modified and a new CRC applied. 

 

DSK6. and DSK7. are now configured as "16-bit" ramdisks.   I also quickly tweaked some documentation, replaced CRACK128 with CRCOS, added FORM v1.23, modified the CYA title screen, and removed the (old) version of DU2K. 

 

GeneveOpSys650-redistributionpermitted2020.dsk 360 kB · 3 downloads

 

If someone could please add this image to WHT that would be appreciated.  The prior release may be archived or deleted, IMHO.  

 

uploaded there to /geneve/mdos  what file is the old one you want gone?

 

Greg

  • Like 2

Share this post


Link to post
Share on other sites
4 minutes ago, arcadeshopper said:

uploaded there to /geneve/mdos  what file is the old one you want gone?

 

Greg

I am thinking Geneve\GeneveOS_650_redist.dsk should be replaced with the 2020 version.  Maybe sometime later this year a few of us can go through that Geneve folder and re-arrange a few things, pick whether to capitalize names for sort purposes, etc. 

 

image.png.575d96e92e695d20c0e9011a3c7f25a4.png

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...