Jump to content

mizapf's Photo

mizapf

Member Since 31 Jan 2013
OFFLINE Last Active Today, 9:21 AM

Topics I've Started

Ninerpedia upgraded

Yesterday, 9:43 AM

Hi all,

 

just a short announcement: Ninerpedia has been updated to the latest MediaWiki version, and user registration is possible again. Registration was turned off for some years now ... nobody really noticed. I have to confirm all account creation requests; I still remember when we forgot to do that and the whole site was turned into a pharma stuff marketplace in a single night (hundreds of pages and hundreds of pseudo accounts).

 

I am in the process of moving MAME- and TIImageTool-specific information from Ninerpedia to my own website (www.mizapf.de) so it will be focused more on real TI family stuff and less on my works. Of course, I'll keep summaries and links on Ninerpedia.

 

I noticed I did not yet set up a favicon. This is my suggestion (until someone else comes up with a better one).


Retailers list (1983)

Mon Apr 22, 2019 9:56 AM

This is what I found in my cardboard box; a list of retailers for TI-99/4A and its equipment, originally from TI Germany. I seem to remember I actually asked for that list back in those days.

 

(The addresses are certainly outdated, the ZIP codes are still the old 4-digit ones, and dealers may have long closed their shop and left the market.)

 

I was living in the Frankfurt area, so I had some choices indeed. Maybe some of the other German users here remember their favorite TI retailer.


Proposal for a new Geneve boot process

Sun Apr 7, 2019 10:13 AM

This is a first concept for a new Geneve boot process, which is implemented in the boot EPROM.

 

Over the years, and in particular after some debugging and disassembling, I found that the existing solutions (0.98 and 1.00) offer some potential for improvement (politely saying).

 

Both boot EPROMs offer to boot from one of several fixed sources. Also, they include code for a low-level access to the storage media. Such code should be part of a driver, and the driver should not be hardcoded into the EPROM, because there is always the chance of having bugs in it, or you encounter a new device that will not be supported this way.

 

Also, booting is performed the same way, once your hardware setup has evolved to a stable state. If you need to press a certain key every time for loading from your favorite device, this is somewhat annoying. Unfortunately, the Geneve does not offer a non-volatile storage (EEPROM) to store user preferences.

 

For that reason, I considered to write a new boot process with the following properties:

  • The EPROM shall not contain any low-level device access code. It contains a fixed list of popular boot devices, though.
  • The boot process is composed of two stages.
  • The first stage consists of loading a boot loader from one device of the built-in list, using the DSR from the device. After successfully loading the first stage, control is passed to the loaded code, and the boot EPROM is no longer needed from there on.
  • The second stage consists of loading a controller-dependent part that loads low-level routines into the system, still using the card DSR (but may also use own code).
  • The controller-independent (CI) loader must be placed on one device of the built-in list. However, it has full control from where to load the controller-dependent (CD) part. That way, a known device may bootstrap any future, still unknown device.
  • Since the EPROM passes control to the first stage, the first and second stage may be combined to a single stage, containing all required low-level routines.
  • In case of a broken boot process, there is an override to force loading from DSK1.

This leaves a lot of space in the EPROM, and I envisage to get a more informative boot screen with memory test output, device detection, and a progress bar for loading. All of these are comparatively simple tasks. Also, the Swan should be shown on the screen, as it is the well-known brand icon of our computer.

 

The typical situations that I have in mind:

  • Floppy only. The disk in DSK1 contains two files: @BOOT1 and @SYSTEM. The boot loader must be selected according to the floppy controller. The first and second stage are contained in @BOOT1.
  • MFM drive. The drive (WDS1) contains the above files. As long as no space bar is pressed, loading will start from WDS1, which is part of the built-in list.
  • SCSI drive. See MFM drive.
  • Floppy and EXOTIC device. The second drive is not part of the built-in list. The Floppy drive contains the file @BOOT1 only. The file is tailored to point to the EXOTIC drive, from where @BOOT2 and @SYSTEM are loaded. This way, the floppy will only be used for the first stage, and most of the code will come from the second drive.
  • SCSI and EXOTIC device. Similar to above; @BOOT1 and @BOOT2 may be combined and put on the SCSI drive, since the SCSI drive is fast. @BOOT2 is tailored to attempt loading @SYSTEM from the EXOTIC drive.
  • Since the floppy drive may always be forced to load @BOOT1, you can do anything you deem reasonable from here on, probably booting a rescue system that you put on DSK1.

I cannot promise this will become real in any shorter period of time, but maybe someone here feels like starting with it, or has another idea.


Good old Scott Adams Adventures

Sun Jun 10, 2018 5:38 AM

When we recently discussed Infocom adventures, I felt like trying Zork and those other games again. But before, I thought, why not give those old adventure games a try, those from Scott Adams. Where we, in today's world, a confronted with games of dozens of gigabytes and most complex gameplay (playing Fallout 4 right now), it's somewhat a nice break to try to solve Pirate's Adventure.

 

I know there are a lot more games for the Adventure module (I even wrote an own one with the Adventure Editor), but I'm limiting myself to the "classic" series from Adventureland to Golden Voyage.

 

Did you play all those games in the past? Try them. And don't look for walkthrus (they are out there, of course); it is possibly to solve them by guessing, trying, combining.

 

I just completed "#5: The Count", which I found best so far. Next is "#6: Strange Odyssey".


Crippled by a Spectre

Fri Apr 27, 2018 12:32 PM

[also posted to the MAME forum]
 
(Find information about the recent CPU security vulnerabilities on Wikipedia: https://en.wikipedia...y_vulnerability) , https://en.wikipedia...y_vulnerability) )
 
It took me some weeks to finally find the reason for the drastic performance loss that I observed since mid-March.
 
During my works on the Hexbus system and the HX5102 floppy drive for the TI-99/8 I found that for no obvious reason, the bench performance of MAME dropped significantly.
 
The 99/8 emulation is pretty CPU-hungry, but since my last HW upgrade to a Skylake system (i7-6700K CPU @ 4.00GHz), these issues seemed gone. The naked 99/8 delivered a bench performance of 350%, which was enough reserve for screen output and the floppy drive.
 
Just about end of March, close to the completion of the HX5102, I noticed that MAME did not achieve 100% emulation speed anymore, which I noticed from the chopped sound. I did another bench test, and got just about 150%. First I thought I accidentally build a debug version, then, a non-optimized version. This was not the case, the build was good. In fact, I found an old build of MAME from June 2017, a 0.186 release, untouched since then. I continued my tests with the 99/4A driver built into that one.
 
Here again, I remembered that the reserve was pretty high, between 800% and 900%. Now, only 300% were reached.
 
I am using openSUSE Linux (Tumbleweed rolling release) and suspected some issue in the kernel, so I started bisecting. The results were not clear; the bisect result on one PC did not match the one on my second PC.
 
I now found the issue, as I believe. When I add the kernel boot parameter "spectre_v2=off", the higher emulation speed is back. Obviously, MAME is particularly affected by the Spectre issue, because it is a heavy CPU-load application. It is not only MAME, though. I am using a Bluray player on WINE, which turned unusable now. I know that I successfully watched a Bluray some time ago with the same system.
A kernel developer explained to me that when you see this:

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Indirect Branch Restricted Speculation, IBPB, IBRS_FW
it means that your system is heavily slowed down, since the much better performing retpolines do not work.
For me this means that my two PC systems are hit back to pre-2011 performance. I have a laptop from 2012 (Core i5 3220M), which now runs MAME faster than my Skylake PC (i7-6700K CPU @ 4.00GHz) and my KabyLake PC (i7-7700K CPU @ 4.20GHz).
 
There are some open points to consider:
* Why is my dually installed Windows 10 still running fast? Maybe Microsoft did not yet deploy the mitigation. When this occurs, I am curious what will happen.
* Is this a failure of the openSUSE people who are tailoring the vanilla kernel to their distribution?
 
For the time being, I seem to be forced to turn off the Spectre mitigation and make my PC vulnerable.
 
Here are some numbers, gained from the current MAME build:
 
With mitigation (current situation)

$ ./mame64 ti99_8 -bench 20
Average speed: 153.85% (19 seconds)
$ ./mame64 ti99_4a -bench 20
Average speed: 298.34% (19 seconds)
Without mitigation (previous situation, now adding "spectre_v2=off"):

$./mame64 ti99_8 -bench 20
Average speed: 362.01% (19 seconds)
$ ./mame64 ti99_4a -bench 20
Average speed: 895.49% (19 seconds)
Note that you may possible be affected only if your system is a Skylake or newer system.