FALCOR4

Posting a cart image of the MG Explorer along with source files. Was fun going back into 33 year old code but time to move to next project. Many thanks to Jon Guidry for his project support and to Fred Kaal for his support and for the generous use of his loader code. Fred, your ModuleCreator is great! Thanks for coding that and Jon, you've had infinite patience helping me, thank you. MGEXP.bin HFE.zip DSK.zip

A pic with the converter/connector turned towards the back

Hmmm, could be in some cases I suppose but I don't believe I'm having that issue. It's 100% consistent for me. However, I didn't want to spend energy on it since I'm on my last harddrive of that vintage. Once it goes completely bye-bye I'll have a Myarc personality card museum piece. I've been pretty much working off the RS232 HDX now and the UberHDX cartridge. Still use the heck out of the GoTek as well (thanks Jon!). Point, better options now than relying on a finicky old HD. :-) And, there's TIPI !!

Ah,interesting. I get the error 6 but under a different set of circumstances. I tried to copy several PROGRM files from the TI through the RS232 HDX onto my PC and got the the error code 6 back. I don't recall if the HDX server locked. But, I was using the old Myarc XB HD disk utilities to move files off of my 10M WDS drive through the Myarc personality card. I just dismissed it because the disk utilities are buggie anyway. I actually had to move the files to a floppy then transfer them to the PC through HDX. It was painful because I have A LOT of PROGRAM files. All the other files; dis/var, int/fix transferred just fine.

Wow....Thanks, this is pretty cool! Never knew that it existed! I was specifically looking for the code for the EA Save; you're a mind reader.

I'd be interested in 4.

Looks like these files are good. Posting..... If you're out there, Mike Dodd, would love to talk to you DSKA0028.hfeDSKA0029.hfeDSKA0030.hfe

Well, this is going back a few years. If memory serves, the GK adds six bytes as a header to the file when you use the "Save Module" function. 1st byte: tag >FF or >00, 2nd byte GROM/ROM number, 3-4 bytes number of bytes to load, 5-6 bytes GROM/ROM address. Don't hold me to this until I check but I think that's probably it. Attached are the source files for the GK loader. Its in GPL and I used the Weiand GPL assembler that Heiner Martin sent me (in German no less!!). Hope this helps. DSKA0073.hfe

When you're done, run the GKTEST (it will pull in GKTESU, GKTESV) file from the GK load module selection. It will run the GK production software that checks a number of things including all of the volatile memory. Selection one is the main program. Selection two will check battery function; you must run selection one first then you can remove your GK, reinsert it, reload the program and go to selection two. Note a couple of things; it will wipe the GK so save your work first. Selection two will hang on "busy...." after the first switch change unless you have a printer hooked up to your PIO port. Just do a GK reset if that happens. It is a bare bones program that doesn't give you much feedback on what it's doing, unless it finds something wrong then it will let you know. So, no news is good news. The source files are there if you want to dig into it. DSKA0035.hfe

Opry99er, Acadiel posted the production test routines that MG used to run on all new GKs. I would use that to check out your unit. It runs through all of the RAM and does an extensive test. Also, there was a modification that MG put out because some units were prone to losing "bits" of memory when the GK was pulled out of and reinserted into a console with the power on. It involves a diode, resistor, cap change on the lower board. That is also posted.

Success!!!!

Hi Opry99er. To start from a know state; did you follow all of the steps starting about 2/3 the way down in the GK manual on page 13 continuing through page 14? Sounds strange what's happening to you.

Acadiel, you have them now. I took a cursory look at the source files and didn't see anything wonky going on so I'm going to assume they are intact.

No, it wasn't in the original files I pulled off the HD. I'm still finding all kinds of stuff from back then; I ran into this one on one of the floppies that Mike sent. I'll post it as soon as I know that I have it all. I was finally successful in getting everything off the drive, I sent you an email. GoTek to the rescue! Much thanks for that.

Agreed. I'll put my CC FDC in maybe this weekend and check the disk to make sure I captured all the material. Am using the Myarc FDC now and it's only a 16 sector/track on the DSDD but the disk from Mike is 18 per. Shouldn't make a difference just reading the disk but stranger things have happened......

Old school. I used the heck out of it when writing the explorer. I'll probably never get rid of it, rpn is so natural for me to use. I have an 12C and 15C as well. Love 'em!

First, is there already a version of the MG Explorer for the Geneve out there? We haven't been able to find one yet. Is there any interest? Years ago Mike Dodd wanted to modify it to work on the Geneve. He spent some time recoding and returned a disk with his initial work. I have nothing after that and I don't know Mike's whereabouts/status today. So, if there is interest and if someone would like to take up the task I would be happy to post what I have. I haven't taken an in-depth look at the changes and I probably won't be able to engage too much on this project given time constraints. If you've good with coding, have good knowledge of the Geneve, have the time and want to take this on let me know. Here is a synopsis of the notes page that Mike sentat the time: NOTES ON GENEVE VERSION OF MG EXPLORER Modified for the MYARC Geneve 9640 Computer by Mike Dodd Nature of this release of Explorer: This version will probably work on a 99/4A, but slllowwwllllyyyy, due to all CRU keyscans being removed.. It would be much better to use Bytemaster's version of EXP for the /4A - this version was meant for the Geneve.. There are two versions on the disk: EXP and EXP1.. EXP loads at >B9C4 and is designed for operation from the Editor/Assembler environment.. EXP1 loads at >A000 and is designed for the Extended BASIC environment.. It can be loaded with the LEXP utility provided on the Bytemaster release disk.. Both versions are >462C bytes long.. Changes: [1] EXP used CRU keyscan to check for CTRL 2-5 when in continuous execution mode.. Changed to use normal keyscan link.. [2] EXP used CRU keyscan in memory editor to check for FCTN-SHIFT cursor movement.. Removed.. [3] EXP used CRU keyscan to scan for SHIFT when in continuous execution mode, for purpose of placing in Turbo mode.. Removed.. [4] EXP had many "Anti-Piracy" checks, to prevent changing the load interrupt vectors, and looking at/altering EXP's memory.. These have been removed.. [5] All auto-repeat code has been removed - they were too fast on the Geneve's higher speed, and the Geneve's IBM keyboard has auto-repeat built in.. [6] If the PC reaches >02B2, indicating a keyscan, the Geneve will execute the keyscan at high speed and return to *R11.. This was changed as the Geneve's keyscan involves memory paging, and would page EXP out of memory, resulting in a lockup.. Unfortunately, this still does not work perfectly, and I'm not sure how to fix it.. The problem is this: when you STEP an instruction, either in single step mode or continous mode, EXP scans the keyboard, using the standard link (see [1] above).. This keyscan almost always grabs a new key first, before the AP program gets a chance to read the keyboard.. Thus, when the AP program scans the keyboard, the keyscan returns a status of >00, since, as far as it's concerned, that key was already pressed.. Which is true.. Then, of course, the AP program scans the status byte and sees that nothing has been pressed, and scans again.. This can continue on forever.. I honestly don't knoww what the solution to this is.. I am welcome to any ideas.. [7] EXP destroyed all memory when CTRL = was pressed to exit.. This has been removed, so that on CTRL =, EXP executes a BLWP @>0000.. [8] colors changed to suit my perverted tastes (I have a monochrome monitor).. You don't like them? Tough - wait for the final release of this.. I'll try to have easily changable colors in it.. Changes planned: [1] Would like to modify EXP to have option to execute DSR calls at full speed, so that programs may call the DSR and still work on the EXP.. This shouldn't be too difficult.. [2] Would like to modify EXP to reside in different memory pages than AP program, so that the AP program could take up as much memory as it wanted.. However, this may be next to impossible to do.. I'll have to do a detailed study of EXP's usage of AP memory.. If the only users of it are STEP and DASSEM, it might not be too difficult.. Otherwise........ could be an incredibly neat trick.. Sure would be nice though - would make EXP the ultimate debugger.. Keep in mind that unless change [2] above is accomplished, memory is very tight.. For that reason, such large features as, for instance, disk catalogs, printer dump, help screens, etc.. will not be considered, _unless_ I can get the above change made.. Even then, I will want to keep it to 32K maximum (it's about 17..5K now, so there would definately be room for expansion), counting code and buffers.. BUT, I would not bet great amounts of money on the success of changing the EXP to reside in different memory banks, so keep it reasonable..

Had a few minutes so I popped the cartridge open and turned the connector around. Works! Much better solution, thanks. The connector on the cable is snug on the top of the console but not objectionably so. Could put a shim under the cart connector but, I'm not going to bother unless the beige console is slightly different and causes an issue.

That might actually be possible, routing it to the right. That is about the only real estate on the top of the cart that you can use or else you'll start running into the components on the inside. There might be space to turn it sideways? Now, your idea to point it to the back would probably work. Let me try that, good suggestion!

Finished wiring in and attaching the RS232 to TTL converter onto my UberGROM cart. Really happy with it!! The converter is about $12 on Amazon, either male or female. Finally, am able to use PC as a file server. Thanks Jon!

Here's LDR1 or, "DISKASSEM" as it is named on the DiskAssembler disk. This is the loader that's launches LDR2 which in turn pulls the program images off and puts them into memory. DskDLDR1.rtf

Attached is the LDR2 listing. You will find this loader in HEX early in the DBLDLIST_c1.rtf file, with the label LDR2. The DiskAssembler production program incorporated it and put it out to disk along with the DD2, DD3, DD4 and DD5 program images. I believe that I also have the first loader as well, the one that loads this one when you launch DiskAssembler. I'll post that one next if it is indeed the correct one. That will complete everything you would need to produce an original DiskAssembler disk (if that's your thing :-). Have fun with it, I hope some of this history is interesting. DLDR2LST.rtf

DELETE FILE DBLDLIST.RTF if you downloaded it. I had part of the listing turned off which contained some important data. The attached file has the entire listing. dbldlist_c1.rtf

I attached a list file for the DiskAssembler production program. I hope it helps and doesn't cause more confusion. I have the loaders that I can attach here pretty soon. I'm trying to recreate the full method we used to make the disks back then for historical documentation. You'll see the the production program uses several memory images when it constructs the disk. I'm trying to find exactly what i used to pull them out of memory to make the files. It may have actually been an old TI program from 1981? Still looking. BTW, this program only ran on the CorComp card. Let me know if this sheds any light on the subject. DBLDLIST.rtf