+jedimatt42 Posted May 28, 2020 Author Share Posted May 28, 2020 (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. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 28, 2020 Share Posted May 28, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted May 28, 2020 Share Posted May 28, 2020 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. Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted May 28, 2020 Share Posted May 28, 2020 Oops. Without the cable it is an 8-bit data transfer. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 28, 2020 Share Posted May 28, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 29, 2020 Author Share Posted May 29, 2020 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 --- Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 29, 2020 Author Share Posted May 29, 2020 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" Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 29, 2020 Share Posted May 29, 2020 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.) 1 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 29, 2020 Author Share Posted May 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 30, 2020 Author Share Posted May 30, 2020 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... 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 30, 2020 Author Share Posted May 30, 2020 (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 May 30, 2020 by jedimatt42 InsaneMultitasker educated me to the fact that FORM3MEG tries to do the full capacity if not requesting the 256k mode. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 30, 2020 Share Posted May 30, 2020 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 > > 1 Quote Link to comment Share on other sites More sharing options...
globeron Posted May 31, 2020 Share Posted May 31, 2020 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 31, 2020 Author Share Posted May 31, 2020 (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 May 31, 2020 by jedimatt42 pictures are beyond me in media-wiki right now Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 31, 2020 Author Share Posted May 31, 2020 @globeron I've written the steps down here: https://www.ninerpedia.org/wiki/Booting_MDOS_from_Horizon_Ramdisk Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 31, 2020 Author Share Posted May 31, 2020 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 31, 2020 Share Posted May 31, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 31, 2020 Author Share Posted May 31, 2020 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'. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 31, 2020 Share Posted May 31, 2020 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. . 2 Quote Link to comment Share on other sites More sharing options...
globeron Posted May 31, 2020 Share Posted May 31, 2020 47 minutes ago, jedimatt42 said: @globeron I've written the steps down here: https://www.ninerpedia.org/wiki/Booting_MDOS_from_Horizon_Ramdisk Thank you! I will try that this week! 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 31, 2020 Author Share Posted May 31, 2020 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... 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 1, 2020 Share Posted June 1, 2020 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. 1 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 1, 2020 Share Posted June 1, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 1, 2020 Share Posted June 1, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 1, 2020 Share Posted June 1, 2020 Sounds good lmk if you need anything else in the meantimeSent from my LM-G820 using Tapatalk 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.