InsaneMultitasker

Reminds me of earlier this year. There were two associates at the end of the aisle looking to ask customers a question about something. I pushed my cart ever closer and one of them asks, “Can I ask you a question?” I said sure, and he asks “do you have any bathrooms in your house?” I said, “no, no bathrooms in my house“. Both just looked at me dumbfounded. They didn’t ask me anything else and I never found out what they were peddling.

The Geneve card type won't show up except for a few conditions where it senses RAM where ROM is typically found (address space >0000->1FFF) AND finds a specific value at >8002. Check the LS244 chips for any shorts or opens.

I revisited the Geneve adaptation of Rasmus' demo and encountered a few bugs. Most notably, I was incorrectly setting the 9938 VRAM memory type to 16K not 64K. Rasmus' rendition sounds so good that I let it play most of the afternoon. The ZIPped files are in TIFILES format. MonkeyIsland2 demo Geneve adaptation 4-2024.zip

Maybe Windows is afraid you are working on a new simulator and is playing hard to get

Fyi, This version of CFG is one rev older than the ‘current’ release. See my previous post. Good progress. Do you have an RS232 in the system? The Geneve rompage entry should not be there for a /4a system. What cards were in the PEB when you took the picture.

Perhaps the RS232 CRU selection "issue" can be resolved if the hardware code & schematics are released. That would allow more unpatched 9902-serial programs to run unpatched. I found a few files I had forgotten about when @Shift838 and I reached out to Custodio. - Updates to MidiMaster for the Nano - version 2.3 and 2.5Z. - Funnelweb 4.40 patched UTIL, FW, and LOAD programs to account for the extra 8 bytes of VDP RAM the CF7/nano use. As far as I can tell, this is the last image I released in 2011, after discovering the XB loader needed to be revised. I included a text file that contains text from the list server post and some information about DSKU. - Telco patch for the terminal emulator portion. Someone had reached out to Charles Earl for the source but as far as I know, we are still waiting. If I come across any related files or source, I'll post them in this topic. MIDIMaster99-v25Z-standard-NANO AND UBERGROM.dsk MIDIMASTER V23 NANO.dsk Funnelweb40pat-nanopeb problem.dsk TELCN for nano.zip !CF7 Compact Flash FWEB DSKU fix and ideas.txt

Thanks. No rush. I sent the HFDC CRU fix to 9640News a short while ago. There is more work to be done across the OS/GPL/EXEC but that is for a later release.

OK, one last mystery solved for the day. These three HFDC CRU bit log errors weren't too hard to find. The GPL /4a mode powerup starts by setting the CRU to >1100 then clears 8 CRU bits with a LDCR @H00,8 statement. Could this cause any adverse effects to the cards normally at >1100 (TI FDC, Myarc FDC, CorComp FDC, Myarc HFDC and now TIPI) ? If the card allows CRU bit changes without an SBO 0, I'd say "maybe"; I don't think many cards besides the RS232s allow this. I'll look through older GPL releases just in case this line of code was accidentally moved from some other routine. Regardless, I'll clean this up.

Yes. If CYA is required, then either the LOAD-SCS loader is an earlier revision and/or the current loader needs to be updated to set the proper device flag for the OS. I recently mentioned this elsewhere, though it might have been lost in the back-and-forth.

@mizapf and @9640News The reboot problem I described in item #5 (April 14) is precipitated by an ancient piece of 8-bit ramdisk code in the Geneve EPROM. The early ramdisk addressing was 8-bit wide and the Geneve's EPROM uses low-level CRU access disassembled from JPH's EPROM-based 8-bit ramdisk DSR. It is for these two reasons that SYSTEM-SYS must reside within the first 1023 sectors of any size ramdisk. When the system is first turned on, I believe that all ramdisk CRU address bits are set to zero (in 8 and 16 bit ramdisks) allowing the Geneve EPROM to find a bootable ramdisk. If the last sector accessed before a reboot is #1023 or higher, the MSByte in the 16-bit ramdisk CRU address is no longer >00. Since the EPROM's routine operates on 8 bits, the MSByte is never cleared, sector 0 cannot be found, and the 16-bit ramdisk is "invalid" as a boot device. There are potential action items for both MAME and the Geneve OS: 1. If a hardware reset and/or card deselect (SBZ 0) is expected to clear the Ramdisk's CRU RACK selection bits, then MAME may be a contributing factor. Review whether real hardware matches emulation. 2. If a hardware reset and/or card deselect does not clear the Ramdisk's CRU RACK selection bits, then we have a few software changes to consider: a. Upon completion of any Geneve OS 16-bit IO, clear the CRU's MSByte before exiting the DSR. b. Update the Geneve boot EPROM to clear the MSByte of the CRU address* before selecting the RACK. c. Optional: incorporate the Geneve OS 16-bit routine into the EPROM, to resolve the 8-bit sector limit* *This might require testing the ramdisk hardware to determine if it is 8- or 16-bit.

No. The hard-coded CRU for SCSI, TIPI, and IDE are a thing of the past, barring any mistakes. The SCSI and IDE loaders were locked to specific CRUs, I do not know if the latest version corrects that as the source on Github is older than the releases. (We knew this but just mentioning for reference)

I re-enabled the debug output in the OS and reviewed what is happening in the OS. The seemingly delayed "closing connection" and subsequent "connection established" activities are a side effect of the Geneve OS powerup routine. Instead of immediately resetting the TIPI card during a powerup, the OS sets a flag that forces the TIPI to restart the next time it is accessed. This does not adversely affect the TIPI nor its operation but it is misleading in the sense that the TIPI powerup can happen seconds or hours later. The OS delay explains why the MAME error logs do not match what I expected. Alas, the code does not lie! I do not recall why I encoded it this way, other than it may have been a forgotten precursor to the later cleanup and updates I made to the master DSR and the OS XOP powerup routines. I will think about a way to align the TIPI powerup with the other device powerups. Per your PM, I enabled the TIPI "Wait for initialization" switch and this seems to have resolved my earlier problem. (edit: related to MAME lockup up during a TIPI access following a powerup)

I've attached the source to the modified DM1000 v3.5 that was used with the CF7 (and should be compatible with the nano) cfmgr.s.txt

Good. Very good. Stick with CRU >1200 for any instructions you prepare for the Geneve. The loader will need to be updated to support any CRU, as noted earlier, to use other CRU bases.

What was the end result of the EPROM versions?