windenntw

This was exactly one of the many hardware projects that were published in the spanish magazine microhobby.

Long story short: it added 16K of RAM that was mapped at 0, and allowed both manual control with buttons or software control via a port to decide if it is mapped only for writes or it is mapped for both reads and writes.

https://microhobby.speccy.cz/mhf/103/MH103_20.jpg https://microhobby.speccy.cz/mhf/103/MH103_21.jpg https://microhobby.speccy.cz/mhf/103/MH103_22.jpg

https://microhobby.speccy.cz/mhf/104/MH104_22.jpg https://microhobby.speccy.cz/mhf/104/MH104_23.jpg https://microhobby.speccy.cz/mhf/104/MH104_24.jpg

And that's why AmigaOS allowed a MEMF_REVERSE option in the call to the memory allocator ( http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodo... )

Sometime in 95 or 96 recall making a very very simple OS patch that would force all allocations > X size ( 1KB or something like that ) to use MEMF_REVERSE and that made wonders to reduce memory fragmentation :)

Well written, good content, doesn't try to sell random junk, +10 would read again :)

Correct, but also beside the point.

To do it in almost-plain C, you'd need fairly complex macros that are more difficult to write correctly.

To do it in plain C without macros, or plain C++ without templates... you'd need to work out the combination of the template expansion yourself and write down a piece of code that is more likely to have bugs and more difficult to understand.

This is called template-based compile-time programming.

By making 3 instances of linear_feedback_shift_engine class template ( and 2 of xor_combine_engine ), you are forcing the compiler to expand the code exactly as-is 3 times, each with different parameters.

The parameters to the template are constant, therefore the compiler can easily look at how they are used and you are guaranteed ( even in a 1999 c++ compiler ) that the compiler will look at the copies of the code and merge them as much as possible into a single piece of code... which is the one that you see when you decompile the code.

So in summary, it means that you get to write fairly readable code while the final binary is fully optimized as-if you had spent the time merging all the variants as needed for the specific constants.

This is essentially the way many 8 bit games did 3d rendering ( for example the world famous Elite )... you just need two tables, one linear2log and another log2linear, with careful measurement of the ranges and number of elements needed in you application ( which is easy for inference ).

ps. Also used in the original circuits of the Yamaha DX7 synthetiser ( https://www.righto.com/2021/11/reverse-engineering-yamaha-dx... ).

Greetings from Spain!

We somehow got a copy of Defy diskmag, started swapping with Cro^Cydonia and got to enjoy Satisfaction Guaranteed by Pearl :)

I always did all my small tools and stuff in blitz basic 2, would dump binary file and incbin them in Devpac.

-- winden^TNC^Network

[ https://www.pouet.net/prod.php?which=14404 and https://www.pouet.net/prod.php?which=7645 ]

Can confirm all sceners call it sinus in Spain :)

Thats an excellent idea. I've created https://gemini.google.com/gem/17xMogBqRSc2AtdCC-WRfObgHcceD0... and tested it with a couple conversations and it works great :)

Protip: all modern monitors and TVs can still run at 50HZ and you can configure Linux to use it all the time --> zero vsync micro jumps when running european software under ZX, Amiga or C64 emulators :)

The memory requirement is actually not a problem, because you may be able to stream the mp3 from a harddisk ( easily 159 KB per second from a 2.5 inch ide disk when used on a 7mhz 68000 of amiga 600) or maybe even from a floppy ( 10 KB per second on a double density floppy ).

The actual problem is that mp3 decoding requires lots of math, and the total cpu usage to decode at 22Khz mono is the equivalent of a 68030 running at 50mhz, which is more or less 5 times as much CPU as a 68000 running at 16mhz.

For me: January = up, April = left, July = down, October = right.

Never sure why I did this association, maybe it comes from a drawing in a book I read when I was six or somthn?

Here is one in plain 68000 assembler.

  move.b #200,d0
  move.b #100,d1
  add.b  d0,d1   ; 8th bit goes to X flag
  subx.b d0,d0   ; d0 = $00 or $ff depending on X flag
  or.b   d0,d1   ; d1 = 255 if there was saturation

You can do the same with all others that somehow store the 8th bit carry somewhere then allow using it for substraction.

For me https://demozoo.org/music/249024/ from the Deep Remix is their best coop.

IMO the first graph would make a lot more sense when plotted in log scale.

Also this way of framing "As of February 2026, the US dollar has lost 96.9% of its purchasing power relative to January 1914. This means that $100 in 1914 would buy only approximately $3.05 worth of goods today" is of course math-correct but difficult to understand intuitively.

I think it makes more sense to explain it in the opposite direction or in both directions: "$100 in 1914 would buy only approximately $3.05 worth of goods today, or equivalently, $100 in 1914 is worth ~ $3278 nowdays (because 100 / 3.05 ~= 32.78 "

This also makes it easier to understand that the term "millionaire == person that has 1 million USD" only makes sense around 1914, because the equivalent amount of wealth nowdays would be "millionaire == person that has 32 million USD"

Anyways, I liked a lot this visualization https://mlde8o0xa4ew.i.optimole.com/cb:VNTn.d9a/w:auto/h:aut... that visualizes the compression in time of the big value changes.

100 times this

What do you mean "tests"?

Single Malt, specially Islays, are still very much welcomed :)

Get her to try https://www.escapemotions.com/products/rebelle/about , it is reaaaaally close to the original watercolour finish.

You can already get that by replacing the cpu with a pistorm:

https://linuxjedi.co.uk/2021/12/27/800mips-amiga-with-emu68-...

Yes, it has a low-pass-filter that you can turn on or off. See

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...

and more generally:

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...

I took a small look at your repo and noticed a possible issue: while Gravis Ultrasound did linear interpolation of samples [1], on Amiga all sample replay was strictly non-interpolated [2] ... essentially on each display scanline the hardware would check the period down-counter and load the next sample if zero was reached.

cf:

[1] http://www.gravisultrasound.com/files/documentation/GUSFAQ.t...

[2] http://bax.comlab.uni-rostock.de/dl/Paula_SystemTheoretic.pd...

This one is ready made: http://www.apollo-core.com/v4.html

excellent, thanks!

so the traced calls would more or less be:

https://sources.debian.org/src/glibc/2.33-3/sysdeps/m68k/tls...

https://sources.debian.org/src/glibc/2.33-3/sysdeps/unix/sys...

Maybe it is all related to errno needing to read the base TLS pointer? https://sources.debian.org/src/linux/5.15.15-1/arch/m68k/ker...

Sounds like we'd benefit from placing the result of calling sys_get_thread_area(void) in the VDSO area and updating it from http://lxr.linux.no/linux+v5.14/arch/m68k/include/asm/entry.... every time we do a process switch

Could you post a bit more info about that binary? (eg: run ldd to dump the used libs, etc)

Could you get some kind of stack trace at the time of the get_thread_area call?

I'd like to be able to pinpoint the call(s) somewhere in

https://codesearch.debian.net/search?q=get_thread_area&perpk...