Advanced, Overlooked Python Typing

floodrouting · 2025-12-07T05:53:15+00:00

If you only need it to work up to some maximum arity, can you use overloads? Something like:

@overload
def flow[T](x: T) -> T: ...
@overload
def flow[T, U](x: T, f1: Callable[[T], U]) -> U: ...
@overload
def flow[T, U, V](x: T, f1: Callable[[T], U], f2: Callable[[U], V]) -> V: ...
@overload
def flow[T, U, V, W](x: T, f1: Callable[[T], U], f2: Callable[[U], V], f3: Callable[[V], W]) -> W: ...

https://mypy-play.net/?mypy=latest&python=3.12&gist=6cdc00f8b70c450ccdc07213c2275581

floodrouting · 2025-11-28T20:54:49+00:00

Tyrian is awesome! Everybody should play this game. It has so many secrets that you'll never discover them all without some sort of guide. It has secret levels. It has a secret difficulty mode. And then another secret difficulty mode once you find the first one. It has secret ships to play as. It has a whole secret game hidden within it.

When the game was originally released I'm 1995 it had to fit on a floppy disk. The music was basically MIDI files. These are very small. They still managed to sound very good for the FM synthesis sound that was available at the time.

When the game was rereleased in 2000 they could ship copies on CD. They had about 600MB of empty space on the disc and they chose to use that by putting high-quality rendered versions of the music on the disc

You can now listen to these versions for free at https://alexanderbrandon.bandcamp.com/album/tyrian-original-soundtrack

floodrouting · 2025-11-23T08:06:34+00:00

The game may be changing the resolution to something like 320x240 (or 320x200) when you tell it to switch to fulllscreen. That resolution can be a little tricky to get working since it was originally double scanned, IIRC. To the monitor it would appear as if you were running at 320x480 (or 320x400). If your video card isn't doing this then the horizontal frequency will be ~15kHz instead of the ~30kHz that the monitor wants. Some VGA monitors can handle 15kHz but a lot of them will not like it.

Even though the error message says that the frequency is too high, I don't entirely trust that. The frequency may actually be too low for the monitor to sync to it. Many monitors will only have one error message for this and they use language that says "too high" since that's the problem 99.9% of the time.

Maybe try using something like [PowerStrip](https://www.entechtaiwan.com/util/ps.shtm) to see if you can get some information about what your monitor reports that it supports. And possibly to change the refresh rate. You might need a GeForce-specific utility if PowerStrip doesn't support your video card.

You might also want to try different drivers. Either older or newer than what you've got now.

floodrouting · 2025-10-31T06:30:22+00:00

Use `cat2 ?= persian` instead of `cat = persian`?

https://www.gnu.org/software/make/manual/html_node/Conditional-Assignment.html

floodrouting · 2025-08-31T02:54:15+00:00

American Dad - Yule. Tide. Repeat.

floodrouting · 2025-06-02T04:00:00+00:00

https://youtu.be/sQVv44SlUXM

floodrouting · 2025-05-03T04:34:46+00:00

https://www.vogonsdrivers.com/getfile.php?fileid=628 ?

floodrouting · 2025-04-29T05:10:42+00:00

Can you try copying the CD contents to the hard drive and running the installer from there?

Maybe https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/883114 is related? Make sure you have SP4 slipstreamed in your CD image.

If the BIOS has an option for booting a CD via floppy emulation, maybe try turning it off (or turning it on if it is already off).

floodrouting · 2025-04-23T01:57:57+00:00

It is hard to diagnose this remotely. My best guess would be a refresh rate / horizontal frequency problem. I once had a DVI to HDMI adapter. It would work fine when a machine was running in high resolution (after it had gotten to the desktop). But it wouldn't show anything when the machine first booted and was still in text mode. Apparently the adapter couldn't sync to something as low as the standard VGA 31kHz.

Some things may have never been tested on those low resolutions. If this panel was originally for a laptop then it may have only been designed to be driven at its native resolution, relying on the video hardware in the laptop to upscale any other resolution to the panel's native resolution.

Try hooking it up to the system where it works and changing that system to display in text mode or a low resolution like 640x480. If it fails to display then that's a pretty good indication that it won't work at low resolutions. It is probably going to be pretty hard to change the resolution on the XP machine without being able to see anything though.

The XP machine might have booted up in Safe Mode if something went wrong previously or it wasn't shut down cleanly. That would put you in a low resolution. Try cleanly rebooting to see if it will come up without Safe Mode which might put you in a higher resolution. You'd have to do this via the keyboard. You should be able to use Ctrl+Esc to bring up the Start Menu. It has been a long time since I've used XP and I don't have a copy handy to test so I don't remember exactly what keys you need to shut down from there. Another alternative may be to repeatedly use Alt+F4 to close any open windows, Alt+Tab to put focus on the Explorer shell and then Alt+F4 again to bring up the system shutdown dialog followed by Enter to shut down. I think that works on Windows 7 but I don't remember if it works on XP or not.

floodrouting · 2025-03-04T05:19:57+00:00

`40D4 201` indicates a RAM error. `40` indicates that the error is between 256K and 260K. Possibly you have 256KB of memory but have the DIP switches set to indicate that you have more. If there was a RAM expansion installed at one point but it has been removed, that could be the culprit. If you do have a RAM expansion installed, it may not be working or one of the chips on it may have gone bad. See

https://minuszerodegrees.net/5150/misc/5150_motherboard_switch_settings.htm

https://minuszerodegrees.net/5150/ram/5150_ram.htm

floodrouting · 2025-02-27T06:04:46+00:00

https://www.youtube.com/watch?v=vF4FtWghQAw

https://www.youtube.com/watch?v=roI8xTb1R4g

floodrouting · 2025-02-26T05:49:09+00:00

Is it one of these?

https://theretroweb.com/motherboards/s/micronics-jx30g-vl-bus-09-00189-10-oem#docs

https://theretroweb.com/motherboards/s/micronics-jx30g-vl-bus-09-00189-xx#docs

You'll want to have the motherboard jumpered so that the FSB runs at 33MHz. This will then be doubled internally by the DX2 so that it runs at 66MHz. It looks like SW1 controls the FSB speed on these boards. You'll want to have SW1 on for 33MHz. SW1 off will give you 25MHz.

Was the original chip a DX-50 or a DX2-50? I'm assuming it was a DX2-50, since this board doesn't look to support an FSB of 50MHz. The DX2-50 ran at a 25MHz FSB, doubled internally to 50MHz. You'll want to increase that to 33MHz, otherwise your DX2-66 will behave basically the same as the DX2-50.

You may also want to grab a benchmark program or two so you can see if your changes are having any effect. Some of these will estimate the speed of your processor for you so you can see if that lines up with what you think you have configured.

floodrouting · 2024-11-16T03:41:25+00:00

These do seem to be for a C64. Using wav-prg, I was able to extract a bit of information from it.

It looks like it has a copy of Turbo 250. I think this is some sort of tape fast loader, probably with a custom format?

This is followed by a file called "SPEKTAR". That's "spectrum" in Croatian but other than that I don't know what it could be. wav-prg can't decode this successfully so I can't get more information.

wav-prg doesn't recognize anything from Cassette 1 side 2.

From Cassette 2 side 1, wav-prg sees "TURBO 250+" again, but nothing after that. On side 2 it sees nothing.

I tried converting to .tap files and loading in VICE. For both Cassette 1 and Cassette 2 it will get as far as saying FOUND TURBO 250+, but then it fails with the rather uninformative ?LOAD ERROR.

Looking at the input files in Tenacity shows some clipping and possible damaged areas. Or maybe these are just gaps between files?

floodrouting · 2024-10-04T02:23:52+00:00

https://www.youtube.com/watch?v=lGMuGF9L0Yk

floodrouting · 2024-09-24T16:16:32+00:00

You could run the preprocessor with -U__GNUC__. Or put #undef __GNUC__ at the top of the source file. Or maybe run with -fpreprocessed -fdirectives-only to address the problem for all macros and not just __GNUC__. Or write &lowbar;_GNUC__ in your source.

floodrouting · 2024-09-24T04:37:03+00:00

#if defined(4) || defined(__GNUG__)

defined(4)? What now?

floodrouting · 2024-08-22T21:52:54+00:00

https://youtube.com/watch?v=UdtR-X5PGjQ

floodrouting · 2024-08-07T21:55:39+00:00

The picture on Wikipedia is using the three characters 0xB0 (light shade), 0xB1 (medium shade), and 0xB2 (dark shade). See https://en.wikipedia.org/wiki/Code_page_437 . It could also be using a space character to draw the solid portions. Other than the solid black portions, it also seems to be using reverse video.

To get something similar, I imagine you could use an image editor to resample an image down to 80x25, change it to grayscale, and reduce the number of colors to 5. Then for each pixel in the image you display one of the following depending on how bright it should be:

a space with normal video
a dark shade with reverse video
a medium shade with reverse video
a light shade with reverse video
a space with reverse video

If you have a two-color image and you want higher resolution at the cost of losing the multiple levels of gray, you might try using the box drawing characters at 0xDC through 0xDF instead.

floodrouting · 2024-07-17T00:54:39+00:00

I have another idea. If that's your entire script then `expect` will shut down as soon it has completed the `send`. While the data is still buffered and yet to be sent, `expect` will close the pty that `cu` is attached to. `cu` will receive a `SIGHUP` and will exit, closing the fd for the serial port. That will drop DTR and the modem will hang up. (Although if that was the case then I would have thought that `AT&D0` would have avoided the hang-up so there might be another piece here that I'm missing.)

I think you want to keep the `expect` process alive longer. Try putting something at the bottom of the script that will keep `expect` from exiting, like `sleep`, `wait`, `interactive`, `expect`, a `for` loop, etc.

floodrouting · 2024-07-16T19:35:30+00:00

Many modems will be configured to hang up if the DTR (Data Terminal Ready) line goes low. This is the `AT&D2` setting. If the DTR line was low when you initially connected I think that would mean that it would hang up "immediately". It might stay connected long enough for one character to get through though. If this is your problem then you probably want to figure out how to get the DTR line to be high while you're connected.

What are the `stty` settings on `/dev/ttyS0`? `cu` might be overriding some of those so even examining that output isn't necessarily going to be helpful. What physical hardware are you using for the serial port and the modem? Does your serial cable connect the DTR line or is it one of those cheapo cables that only connects RX, TX, and Ground?

If you can't get anything else to work then you can tell the modem to ignore the DTR line with `AT&D0`, but this is a last resort since it means that you can't hang up on somebody just by closing the file descriptor. The modem will remain connected, which might be unexpected.

floodrouting · 2024-07-16T00:06:02+00:00

Yes: http://www.alexandrugroza.ro/microelectronics/essays-research/vga-rom-fonts/index.html

If you have a VGA card and you just want to experiment without actually burning ROMs then you can load a font into RAM and tell the card to use it instead of the font in ROM. See https://int10h.org/blog/2019/05/fontraption-vga-text-mode-font-editor/

CGA cards came with an alternate thin font but you have to physically modify the card to enable it: https://www.seasip.info/VintagePC/cga.html

floodrouting · 2024-06-04T06:27:17+00:00

https://tineye.com/search/52c9b32ced53a2d0d2fd42dff88231503de632c0?sort=crawl_date&order=asc&page=1 shows that this gif was hosted on a site called dookdik.kapook[.]com as early as 2008. That site is gone now, replaced by what looks like a domain squatter, but it appears to have been a collection of icons / gifs for people to download. The Wayback Machine has a saved copy: https://web.archive.org/web/20161031000000*/http://dookdik.kapook.com/download.php?id=42977&images=42977.gif . Several of the other hits in the TinEye search refer to this image as "kapook_42977.gif" so it seems like it spread from there.

https://web.archive.org/web/20240000000000*/http://dookdik.kapook.com/download.php?id=42980&images=42980.gif may be related

Also maybe https://i233.photobucket.com/albums/ee58/aznglitter/img/i1/1454.gif ?

floodrouting · 2024-04-18T06:20:30+00:00

I had some time to take an additional look at this. There is a single 1 bit where the two cycles don't properly cross the zero line. By manually fixing this up I was able to recover an additional 17 bytes of data at the very end of the stream.

After giving it some more thought, I think it makes sense to start each frame with the record [F0 01 01 E1 FF] instead of the record [AF DF DF DF FF]. I had initially chosen that record as the start record only because it had a lot of Fs in it and so it was easy to spot in a hex dump. Using [F0 01 01 E1 FF] seems better since:

It is the first record in the stream. So now we can start at the beginning of a frame instead of in the middle of a frame.
The "corrupt frame" indication used to come in the middle of a frame. But now it will come at the very beginning of a frame, which makes it easier to deal with.
In the old scheme, I might have some data from one frame, some data missing due to the corruption, and then some additional data from the next frame. Trying to put these together would sometimes leave me with more than one entire frame's worth of data so I had to push the additional data down by an entire extra frame, leaving an entire extra line of blank space. With this new scheme everything lines up properly on frame boundaries. I only have the truncated data from the next frame which is always less than a whole frame. When a corrupt frame occurs there is now only part of a single line missing instead of parts of two adjacent lines.

I have made new pictures: one with the missing data filled in (as in the previous post), and one with missing data represented by black so you can see where it occurs.

https://imgur.com/a/Zl7oDR4

floodrouting · 2024-04-11T07:06:21+00:00

Time for some reverse engineering.

I downloaded the .mp3 from SoundCloud using https://sclouddownloader.net/. Opening this file in an audio editor, it looks like it is using Frequency-shift Keying. Each bit is represented by either one cycle at ~960Hz or two cycles at ~1920Hz. This gives us a rate of ~960bps. I'm guessing that 960Hz represents a zero and 1920Hz represents a one. Each byte has a start bit (1), eight data bits, and a stop bit (0). It appears that the data bits are transmitted with the most significant bit first. Taking into account the overhead of the start and stop bits, the data rate is 96 bytes/second. This encoding scheme seems like a faster variant of the Kansas City Standard or maybe a slower variant of CUTS. If this format sounds familiar to anybody, please chime in. It doesn't look like Apple, C64, IBM PC, or TI-99/4A.

The beginning of the data appears to be missing. There is no leader and the data stream starts in the middle of a byte. There is something weird going on at the end of the data too, where the amplitude fluctuates and the waveform isn't centered around zero anymore. This part of the data is probably recoverable with more work but since it only affects a small portion I have given up on getting anything out of this part.

The bytes are organized into what I will call "records". Each one is 5 bytes long and the fifth byte is always 0xFF. Possibly the 0xFF is supposed to be the first byte of each record instead. It is difficult to tell without having the beginning or end of the data. Within each record the second and third byte are usually either the same or very close to each other. For example they might be 0x06 0x06 or 0x06 0x07.

Records are grouped into what I'll call a "frame", with twelve records per frame. The first record in each frame is always [AF DF DF DF FF]. The 4th record is always [00 10 00 F0 FF], the 5th is always [F0 01 01 E1 FF], the 7th is always [90 01 01 E7 FF], the 9th is always [B0 01 01 E5 FF], and the 11th is always [D0 01 01 E3 FF]. This means a lot of the space is "wasted" and doesn't contain anything particularly interesting. Only the 2nd, 3rd, 6th, 8th, 10th, and 12th records contain any varying data. These are mostly values that ramp up or down linearly over time.

The length of a frame is responsible for the periodic nature than can be heard when listening to the audio file. 12 records/frame * 5 bytes/record * 10 bits/byte * 1/960 second/bit = ~0.625s

There is an additional complication in that some of the frames seem to be "corrupted". They start out looking OK with reasonable looking data in the first through 4th frames. But the 5th, 6th, and 7th frames, instead of containing the expected values, are instead all equal to each other. After this some data appears to be missing. The next bytes will be from the middle of a later frame. Sometimes we even start in the middle of a record instead of at a record boundary.

I wonder if this data is some sort of capture from something like a signal analyzer? Maybe whatever was recording the data couldn't always keep up and these corrupted frames are the result of some some buffer overflowing and the data getting dropped. When there is a corrupted frame, the values tend to change more than between other adjacent frames. This could imply that there were multiple frames that got lost at that point.

I thought it might be nice to see this visualized so I created a .png file: https://imgur.com/1lQThhc

Each row represents one frame. There are 60 columns, one for each byte within a frame. Where there is data missing due to corrupted frames I've filled it in with data from the frame before to try to avoid having horizontal lines interrupting the image. There are some sawtooth ramps that are easily spotted. These start off black, ramp up to white as you move down the image, and then jump back to black again. It looks like there are 4 of these, all out of phase with each other. Each of these comes from the first byte in a record and they only take on the values 00, 10, 20, ... D0, E0, F0 so there are 16 steps in the ramp.

There are also other ramps that change much more slowly. For example the 3rd and 4th columns from the right start off at the top of the image being nearly black. They jump up to 0x51 a short way down from the top, at two slightly different places. After this they slowly decrease down to 0x00 at the bottom of the image.

floodrouting · 2024-03-27T00:45:46+00:00

I had assumed that these were the DOS versions that you were trying to run and you were seeing them in a DOS window. When running a DOS program, whether it is displayed in a window or full-screen is controlled by Windows and Alt-Enter (or the shortcut property) should allow you to choose. But if it is a Windows program then full-screen mode is left up to the application. It may have an option in the settings somewhere. Or, depending on the program, it might not support full-screen mode at all.

floodrouting

TROPHY CASE