mizapf

For a short moment, I saw a half-naked Tom Hanks shouting "I HAVE MADE FIRE!"

When I am hit by a rock or a diamond, I just see a field of 3 by 3 diamonds, hear "try again" or similar from the speech synthesizer, and the time keeps counting down. Do I have to press the space bar to continue?

I fully agree with Ralf; do it the Unix way - no bells and whistles, do only the job you are supposed to do, and VER is actually not expected to clear the screen. Maybe we will have a more powerful shell for GeneveOS one day, and then the simple commands will become very handy when we want to write scripts.

My idea would then be to write a SYSTEM/SYS for A: whose only task is to call the SCSI card to load the real thing. I already merged the existing commented source code with my own disassembly.

Can SYSTEM/SYS have any size (for the 0.98), in particular, smaller? I may find out from my disassembly, but maybe you have the information at hand.

Yes, for the 0.98. I did not upgrade my EPROM, and I'd favor a "soft" solution that does not require replacing the EPROM. The point is that I'm doing most stuff in MAME, and it's not really worth doing changes to my real Geneve for those rare occasions when I use it. However, when I actually fire it up, I always have to wait for my floppy to boot. By the way, the idea of having a primordial loader on a supported drive that loads the main OS from a definable source is what I proposed some years ago (but I did not find enough time to further work on that concept).

Is there a way to split the loader on a non-PFM SCSI system? A short SCSI loader for DSK1, and the rest of GeneveOS on SCS1? Right now I'm booting by DSK1 only; this would certainly be helpful.

This is most likely not the reason for a crash or whatever reaction the emulator produced. I tried it by myself, used the old GROM dumps, split in three 8K chunks, and replaced the official GROM dumps (6K) by them. I'm getting the length and CRC warnings, but the emulation runs normally. Even if you found a working solution for you, I would really appreciate any further information about the failure. We can do that by PM if you prefer.

If you decide to use MAME, just send me a PM and we can figure out what is required to be done.

Splitting and pasting together is not a complex job; if I were to do it, I'd set up a bash script that does the whole job for me, calling it "updgrom" or so. If you're using Windows, this should also be possible in the Powershell or with Cygwin.

Why is it a problem to split your GROMs into several files?

I don't think it was a security issue; IRC dried up like most other social networks because of that d*** *u***i** WhatsApp / Facebook.

If it's a GROM, it should be readable in the console. This is also interesting for emulation.

Are the files TUTANKHAMC.bin and TUTANKHAMG.bin genuine dumps of the two chips (nothing modified or rearranged)?

I'm not sure how the partitions are organized on the SD card. But the advantage of a single partition is that you can easily dump the contents on your PC drive and upload it back again, and you can work on that dump with TIImageTool.

Does Tutankham use full 8K "GROMs" (that is, emulated GROM)? Searching the forum I found that @Ksarul once reported that there is a prototype cartridge; any pictures? What kinds of ROM chips are used? (I need this information for the ZIP version.) I played Tutankham shortly, reaching level 2, so far no crashes. The RPK below is defined as "gromemu" (8K GROM). The above one was "standard" (6K), so if the 8K space is used, it will fail at some time. tutankham.rpk

As for the concern that a rogue repository could compromise a system, the usual Linux installers give a warning when you switch a provider. For instance, in openSUSE that I am using, if there is a newer release of a package in another repository that I registered, you get some options during installation like "keep the older version" or "change provider and install newer version". Hence, if Microsoft intended to replace vital components, you would definitely get a warning, and you would have to confirm the change. However, I believe that during the last two decades, Microsoft has "learned to live" with the few percents of non-Windows users and are even providing software. I'm regularly using the Linux client of MS Teams, for instance. This is not like 20 years ago when they called Linux "a cancer". Focus has shifted more to online services in recent times.

I mean, it may be possible to implement - if somebody cared for reimplementing the VDP as a true processor. Currently, it is (not very MAME-like, in fact) implemented as a simple slave device that only does its rendering by itself, but shows no real cycles for memory and register access. And if somebody did, this will cost some percent of performance again (I'm already hearing the comments... 🙂 ).

As far as I know, the VDP implementation in MAME does not emulate overrunning.

Remove the repo if you don't feel comfortable with it. This is just a repository and not a backdoor.

See also https://www.ninerpedia.org/wiki/File_systems#Allocation_Bit_Map_2 However, as we recently discussed, we should better stay with 8 sector allocation units, right? This limits the available size to 124 MiB.

"I've nothing to hide." Heard far too many times.

1980s: "Can't wait for all those gadgets and things to come in the glorious future!" 2021: Listening to 80s music and watching classic sci-fi

Well, I'm just jumping up a little because I keep hearing - for the last 20 years - that E-Mail be considered obsolete.

Why would I use anything else than E-Mail for asynchronous messaging? There is no service that comes even close to E-Mail, and if it were not there, someone would have to invent it.