I'm working on TTZ, a sort of, pardon the expression, next-gen terminal protocol.
I wanted a middle ground between web apps and Terminal UI that allows for things like raster images, vector graphics, simple audio support and file transfer; to let me move more apps and workflows from web apps to a lighter experience.
I have an old laptop that I love and is very nice to use, but since it has only 2 GB of RAM, using multiple web apps is out of the question. I live on the terminal and SSH, but it has its own limitations, like spotty support for images, no audio at all, and ReGis (for vector graphics) support is not available in a lot of terminals.
I've recently finished implementing both client and server libraries for multiple languages (with the help of AI), and right now I'm in the process of fully testing and squashing all bugs and inconsistencies. Next, I will port a couple of applications as a proof of concept.
I plan to publish the source code very soon to receive feedback.
What is the difference between the segmentation model used by Intel and the banking model used by a lot of consoles? I've worked with the code of a couple of NES and GBC games, and while banking could be annoying, I never saw it as a particularly difficult model to follow and use. It did require more planning for the various functionality, but it wasn't even the most complex or difficult thing about developing for consoles.
> and while banking could be annoying, I never saw it as a particularly difficult model to follow and use
Segments aren’t conceptually difficult, either, but definitely could be annoying, and certainly were, if you had to access data structures larger than 64 kB.
As to the differences:
- you had four segment registers that you could ‘point’ anywhere, allowing you to access four 64kB regions of memory without changing them (the equivalent of bank switching) (one always was used for accessing the instruction to run, one for accessing the stack, but you could use those for other purposes, too (Could, not SHould)
- segments can overlap. You could set DS and ES to the same value, for example.
Segments also can be moved at 16-byte granularity. If you wanted, you could have DS address address memory range 0x0000 ≤ x < 0xFFFF and SS address memory range 0x0010 ≤ x < 0x1000F.
Banking is different in that the banks swap in and out. The 8086 segments were all available at the same time once you loaded the segment register, and they overlapped.
Banking was one solution to the 1MB limit; was it extended or expanded mode? I can no longer remember, but one of those gave you a 64kb window somewhere above the 640kb limit in the address space not used by either video RAM or BIOS. That window could then be paged around the rest of memory.
Expanded memory is identical to banking. It wasn’t particularly popular since it’s a pain to program and compilers never got around to automatically generating code for it.
*: not actually 4GB, because that makes the kernel code harder to write and tends to lead to bad performance and lots of bugs. They could get 2GB max with the default settings and 3GB with a special configuration.
On the NES, most mappers would control which 16Kbyte blocks from the PRG ROM appeared in the upper ($C000) or lower ($8000) block of the NES ROM space. Often the upper block was fixed because of IRQ/RES/NMI vectors. I think later mappers allowed 8K blocks. So you only had those fixed windows at those fixed granularities, not the 16-byte granular sliding window 8086 offered.
I don't know about DMG/GBC/GBA games. Some very interesting stuff happened on those platforms (e.g. Game Boy Camera, and some game that lets you control a sewing machine in Japan?) and I bet a pure sliding window mapper exists.
The PC Engine/Turbografx-16 had platform support for mapping (specific CPU instructions did it) but it was 8 fixed windows in the CPUs 64K address space that pointed to 8K size offsets in the ROM I believe. SNES had a 24-bit address space and DMA to copy things to VRAM so not sure mappers were really on that platform.
- TTZ: A sort of next-gen protocol for terminals. The basic idea is to create a dedicated terminal protocol that allows for more features and less legacy cruft (text and commands are cleanly separated). Right now, I’ve defined the protocol and have a couple of implementations ready. It already supports pictures, vector graphics, and file and audio streaming. I love terminals and TUIs, but I found programming and developing UIs against the standard terminal protocols frustrating, so I tried to design a more "modern" version.
- KingD (temp name): A Linux-based OS that tries to unify the roles of router, NAS, and virtualization platform with a single user interface. In my day job, I need to manage multiple FreeNAS, OPNsense, and Proxmox installations, and I wanted something that "encoded" the common workflows I keep repeating and provided a single centralized platform. I’ve been working on this for a while, and I hope to be able to do a Show HN by the end of the summer.
I did something similar on Windows by creating a "virtual desktop," where I can give the app focus without stealing it from another one. The idea was to basically reimplement RemoteApp without needing a dedicated Windows server.
However, in that case, the app is not visible to the user unless you use "connect" to the virtual desktop; to do it, I implemented (WIP) a simple VNC server in C#.
I wonder if you could do the same thing in reverse and have a cheap way to get multiple inputs.
I would love a cheap way to add 8–16 inputs to my PC; all the audio interfaces I found cost quite a bit.
A Behringer UMC1820 does that combination of things (cheap, lots of analog IO, PC interface) very well. It provides 8 inputs OOTB.
For more inputs, a Behringer ADA8200 can be connected with a garden-variety TOSLINK cable, bringing the total of 16.
Or: Two UMC1820s, clocked together using that same TOSLINK cable. That provides 16 inputs that are all identical and also operating in lock-step.
In terms of cost: A smart way to play with this stuff is to buy used gear, and treat eBay as a long-term rental program. Just buy it, use it, and when you want to try something different: Sell it. It works because the depreciation on stuff like this is basically a straight line once the initial hit of turning "new" into "used" gear is over with.
The long-term rental cost then is mostly a combination of time, shipping expense, and seller fees. Keep it as long as you want. :)
edit: alright. so the UMC1820 is apparently having production issues right now, which constrains supply, so prices are higher than normal. On a normal day, they sell for $229 new. I've bought them for ~$100 used. Things will go back to normal soon enough.
The Topping Pro audio interfaces have ludicrously good inputs. The E8x8 has eight analog ins and eight outs plus more connectivity for $450. It is very cheap for what you get. The inputs are crazy good. $450 is also a good chunk of cash, so…
For the $450 you get a lot of stuff. Preamps for mic and guitar pickups. Powerful headphone amp. It's clearly worth it if you make use of some of it, and potentially even just for the inputs alone. $450/8 = $56 per ludicrously clean input is good.
I bought an E1x2 kind of as a joke. Just to see how bad it was. It's actually really, really good.
And also:
It's actually possible to gang together multiple disparate audio interfaces. Let the audio stack keep them in sync with ASRC. Aggregate Device on macOS can do this. People say you can't but you can. Linux is good for this too. If you find a cheaper per channel input, this can actually be done; Piecemeal it.
Thanks for the suggestion. I was hoping for something cheaper since I don't need really high quality. For now, I'm using a bunch of cheap USB soundcards that are good enough, but having multiple USB devices makes routing hell.
The analog input will use separate ADC modules, just as the analog output uses separate DACs. DSPi itself is purely digital (OK, excepting the PWM based sub out). These modules are just a few dollars on AliExpress for ~96dB SINAD
Yes, but this project doesn't do anything analog to begin with. It could just have several S/PDIF and I2S inputs, and convert that to USB. You probably don't want any processing then, and just pass the digital inputs straight to USB. The limit of how many channels you could simultaneously process would then be the USB bandwidth.
Even worse, the ENOB is closer to 9 bits in testing. It’s got horrible DNL/INL. Totally worthless for any audio unless you’re trying to do chiptunes or something.
Personally, I deleted everything I could but kept the Gmail account for a couple of years with a forward to my new account, and after that, I also deleted it. Google Takeout is a very useful way to quickly create a backup of everything Google.
I know that it is a heavyweight solution, but it could be useful for some situations with old driver/devices/applications. I have some old hardware that is compatible only with pre-WinNT OS, and I could do something similar to provide a simple solution for the end user.
Sorry, I wasn't clear. By old hardware, I meant peripherals connected to the computer via serial or USB. We are at a level of performance where running an entire VM as a driver is kind of feasible, if wasteful.
It's not that wasteful if you don't need this stuff most of the time. I have an old HP laser printer from 2008 or so. Nearly 20 years old at this point. Works fine but HP does not provide new drivers and the current x86 ones for my mac will stop working when Apple stops supporting x86 emulation. HP could fix this but they probably don't want to. There likely is a decent Linux driver for this thing. A solution like in the article, or qemu or docker with some way to access this thing over USB could probably get the job done.
I rarely print anything in any case; which is why replacing this thing is not a really a priority for me. I print something maybe once or twice per year at best at this point. It works and does the job. I can get replacement toner cartridges on Amazon. There are decent non branded ones that are really affordable. I've only ever bought two, I think. I just don't print a lot. If somebody provides something that works indefinitely, I might still be using this thing in another 20 years.
I wanted a middle ground between web apps and Terminal UI that allows for things like raster images, vector graphics, simple audio support and file transfer; to let me move more apps and workflows from web apps to a lighter experience.
I have an old laptop that I love and is very nice to use, but since it has only 2 GB of RAM, using multiple web apps is out of the question. I live on the terminal and SSH, but it has its own limitations, like spotty support for images, no audio at all, and ReGis (for vector graphics) support is not available in a lot of terminals.
I've recently finished implementing both client and server libraries for multiple languages (with the help of AI), and right now I'm in the process of fully testing and squashing all bugs and inconsistencies. Next, I will port a couple of applications as a proof of concept.
I plan to publish the source code very soon to receive feedback.
reply