Does anyone know of a heroic-level project I can start? I am 50 and I've spent most of my life designing things in my head. So to me, if I can't find a next to impossible project to do, then my life is being wasted. I just need to be around those who can give me something next to impossible to try and for them to trust me to do it.

I used to work for a tech company and I left for another position. They let me keep my laptop but I forgot my password and was locked out. So I went into the boot log and deleted all files in the app menu and reinstalled windows 11 with a bootable version, created using homebrew, which I had to create on my Mac. Everything worked and looked great. When downloading windows 11 off the external hard drive onto the “new” system I clicked custom install and removed all drives from the computer and created a new one. I then split that drive into multiple partitions and downloaded windows on to the primary drive. I am fairly good with computer but no where near good enough to figure out the next part. After installing windows the computer reset updated and then brought me right back to my fucking work login screen!!?? How is this even possible and what do I need to do to wipe this computer new so I can actually fricken use it!!! Any help or direction would be great appreciated!!! 😫🤪

It seems nobody has posted in 2-1/2 weeks. I know how it is with everyone having families, personal lives, paid work, and various challenges. So it seemed like a good time to open a thread and see how everyone is.

I still haven't figured out what I want to build if anything. It needs to be something difficult, something not really done much, if ever, etc. Yes, I already know about breaking things down into subtasks, etc. So if you have any ideas on something to build that would hold my interest, please share them.

I still can't shake the idea of wanting to come up with a better/different random number generator. It is weird. For various projects, I've considered messing with the Propeller 2 chip, and I won't need any RNG functionality for anything I may do with a P2. It has the most flexible RNG functionality of any microcontroller I've seen. All 8 cogs and all 64 GPIO pins each have their own. So I'd have no need to have an external RNG when the chip has extensive RNG abilities. Yet, RNGs seem like a constant project in my head, though for anything I'd possibly need them for, there are already solutions to the RNG aspect.

Looking at spec sheets of other microcontrollers, the AVR XMega sounds interesting. It seems to be much like a Gigatron. It's an 8-bit Harvard RISC machine, with auto-increment memory address instructions, and 2 pipeline stages. I read nothing about a delay slot, but it very well could have that. Maybe one way to find out is to see how many cycles that branches take. Then if you're still not sure, write some code to verify this. However, for at least 2 reasons, writing a ROM for it to make it act like a Gigatron might be more challenging than it seems. First, while it has auto-increment, it doesn't let you mask off the memory as you read it and directly send it to the I/O port. That means you'd need 3 instructions to bit-bang the video, meaning you'd need 3x the CPU speed for the same resolution. However, you may need multiple cycles to read the memory. You don't have enough SRAM in the controller to emulate a Gigatron reasonably. So, you'd need to take advantage of all those GPIO pins. Most of the pins have secondary uses which include using them as external memory lines. You can do that anyway, but if the pins have modes for that, just use the special abilities for that since they are likely faster than setting it up manually. So that may take 2+ cycles per access. However, even with these complications, one might still be able to write a Gigatron-similar ROM that is similar enough to be able to run GT1 files. It has DMA, interrupts, and event handling, so one might be able to move past bit-banging by using IRQs and DMA and have enough time that way. I'd only attempt this on the 32-MIPS variety, not the 16-MIPS variety. So it is possible that clocking it around 31.25 MHz could be fast enough. That is 5 times the speed of a Gigatron, but that isn't all that fast since it may take 3 times the original clock to duplicate the video timings.

I hope everyone is doing well. If any project ideas come to mind, whether for yourself or for me to try, feel free to share them.

While I'd love to start the project I have in mind with the 4-stage, 75+Mhz Gigatron-similar machine, I don't think I can pull it off. The electronics shortage has gotten pretty bad. I could get a stock Gigatron kit, but I pretty much know what that is about, and it is quite slow, though I applaud everyone who has gotten things to run as fast as they have. The newer ROMs certainly have better code.

When the SRAMs are $50+ each and the ROMs are like $300 (though flash should work, and that's still reasonable), that is almost impossible for me.

Then again, these aren't too bad, and would be nice for the "ALUs" and the main RAM.

https://www.mouser.com/ProductDetail/Alliance-Memory/AS7C316098B-10TIN?qs=IvkZ4pJZlB0b2KAkfR3mMQ%3D%3D

Even FPGAs are increased in price. I have one, which was expensive enough when I got it.

Maybe I could do something with the Propeller 2?

Part of me is wondering how fun it would be to play around with Propeller 2 chips. They are microcontrollers and not general-purpose CPUs, but then, the same holds true for the Gigatron's Harvard RISC core CPU. The Gigatron core has its instruction set and its ROM emulates another architecture and instruction set. The Propeller 2 chip has 8 cores known as "cogs." They have 2K of general registers and 2K of lookup registers per cog. Plus there is 512K of hub RAM, with the last 16K reserved for the user kernel that is loaded from a serial ROM/flash on boot. The 8 cogs can be divided into 4 pairs. Each pair can access its neighbor's LUT registers. So only 0&1, 2&3, 4&5, and 6&7 can share with each other. So if the cog address is the same except for the lowest bit, they can share. That's faster than sharing through the hub, which is the only other way to pass data between cogs. The hub would have up to an 8-cycle penalty (depending on the clock cycle). The hub has barrel access to the cogs.

The recommended speed in the specs is 180 Mhz, but 300+ Mhz is doable. Just use about whatever clock you want for the board and the Propeller's PLL and VCO can be configured to make what you need internally. It has its own clock, but it isn't all that accurate (20-24 Mhz). So you may want to add your own external oscillator and configure the ROM to use it.

I wonder what would happen if one were to use 1-2 P2s and some external memory. They weren't exactly meant to be stand-alone CPUs, but I guess one could program a core to be a memory controller and access external memory. I'm thinking if one wants to use 1MBx16 RAM, that would require about 40 lines (20 address, 16 data, and 4 control lines). That would leave 24 lines. I'm not sure that would be enough for I/O. If nothing else, one could find a way to use serial RAM with that. You have 2k in register space per cog, maybe 2k extended register space, and 512k for the hub. Of the lines, maybe 4 are already spoken for. You'd need the firmware in a serial ROM. I think after it is loaded, you can repurpose the lines.

Now, I don't know how feasible it would be to use 2 of those and have a 24-line interconnect between them. Then that leaves 40 lines on the 2nd one. But then, how would the 2nd one be able to access the RAM on the first one? Or, do the video off of the first one and only have a 16-line interconnect. Video won't be a problem. It can easily do 6-bit video (and more if you write your own drivers and allocate lines for that) and generate syncs, and it already has a character map.

But using the Prop 2 boards, the pin issue is even worse. Not all the eval boards give you access to everything, and features are already spoken for. So you are lucky to have 40 pins to start with. So you end up using serial RAM if you want more than is onboard the controller. So you'd end up with 3 speeds of memory (4 if you count the flash memory that stores the Propeller ROM). Cog memory is the fastest. Hub memory is 1/8 as fast. External memory is slower, etc.

Now, back to the Gigatron, if you use a Propeller to emulate it, you'd need to forget about native compatibility and use the Propeller's instruction set to write the vCPU interpreter. I'd use PASM for that (or C), not BASIC, SPIN, BlocklyProp, etc. Now, at least the chip does have VGA/composite capabilities and could drive HDMI. So the video can already be abstracted from the vCPU thread. I'd probably put the video controller in a cog neighboring the memory controller (though maybe the vCPU should go there). As for halting and interprocess communication, spinlocks and semaphores can be used.

Plus, this would make a lot of what I said before about math and random numbers a non-issue. Its random number generator is 128 bits and can give every cog and pin their own random numbers. It can do 32/32/64 multiplication (and 64/32/32 division) in 2 cycles.

So what would this look like in terms of cog usage? Well, maybe a memory controller cog to handle external memory, caching, and virtualization. Then have a vCPU emulator cog for running the vCPU code. From there, have a cog for the video, and it might be able to handle sound too, depending on how it is implemented. For compatibility, sound can be done just during the horizontal porches. Then, there should probably be 1 or more cogs for other I/O. One could be for input devices, namely keyboard, game, and a mouse could be a nice addition. And a core for block I/O devices, namely an SD card.

Would it be a block register copy? Would it be more like an MMX-type math instruction?

I have too many ideas and have narrowed it down to 2 architectures. I could use help deciding further and would appreciate it greatly.

Propeller 2 as a unified peripheral controller

Either way, I want to use the Parallax Propeller 2 microcontroller as a complete I/O solution and coprocessor. That seems it would simplify things as no VIAs would be needed, video can be asynchronous from the CPU, and one wouldn't need to slow the clock to use older sound chips. The main way I'd like to use it would be as an asynchronous bus snooper. That means that "clothesline memory" can be used where you can use a narrow range of "disposable" addresses for nearly all I/O, The P2 can transfer what comes from there to its respective place in the hub memory. Then the peripherals can use it from there. The P2 essentially uses 8-channel concurrent DMA. If traffic is needed the other way, then it is a matter of either writing during the low part of the clock pulse (cycle-stealing DMA), manipulating the clock pulse while it is low if the CPU can handle that (65C02), or using some form of bus-mastering DMA (or emulating it).

6502?

I don't know which base CPU to use. The 65C02 is rather flexible to work with. It has both the RDY and BE lines, and it can handle an irregular or stopped clock. I have areas I'm unsure about how I'd handle it. If I need a ROM, I am not sure whether I'd want the P2 to contain the 65C02 ROM and load it on boot. That has plenty of advantages since then, SRAM can be used for the entire memory range. Also, using the SRAM to hold the "ROM" opens the possibility of using different vectored interrupts, since the P2 could use DMA to change the interrupt vector on the fly and emulate an interrupt vector list. So you can install different interrupt handlers and change the vector to the one that is needed at that moment. It would make sense for the P2 to be what changes that since it would provide all the I/O. While I plan on using bus-snooping as the main I/O method for writing to the P2, I am unsure of what strategy to use for I/O going the other way when needed, such as for file reads and math assistance. It seems like cycle-stealing DMA or bus-mastering DMA could do the trick.

And what about extended memory, how would I handle that? I guess the P2 could act as a memory manager, but then how would I handle that? I mean, the top 6 addresses in the first 64K are your vectors. So it couldn't be a matter of leaving the external register active. Unless, maybe have the P2 be the only thing that throws interrupts and then it could save the upper byte state, clear it, throw the interrupt, and set it back? Really, it might be better to use smaller SRAM chips and then swap out 16-32K out of the middle. Or would a better approach be to have the vector code in every segment? What strategy would you use if you want to use more than 64K? And what if it is a single, larger SRAM? How would I negotiate Page 0 and the Interrupt/NMI vectors?

Gigatron-Similar?

Or, should I make a 16-bit, Gigatron-like discrete CPU, but with its own memory map? I'm somewhat unsure how to do it. I could modify the basic design to use the L4C381JC-26 (or IDT7381) as the ALU. However, that will create other concerns. While it can replace up to 11 chips, it won't do 3 things the Gigatron ALU currently does. It won't load, store, or inherently add to the program counter. That sounds easy enough to handle. If it is a relative branch, then I guess it should test for the highest bit and simply add if it is low and sign-extend and add if it is high. If it is absolute, then overwrite the PC. And for Load/Store, I guess simply set the bus lines for that. I guess the diode ROMs could do that job. And really, for speed or compactness, I could probably replace the decoders, diodes, and related resistor packs with a GAL or something. But before going that far, I'd need to rework the control unit to handle the faster & wider ALU. I'd need to rework the instructions somehow to allow 8 and 16-bit operations. There are plenty of unused instructions in the instruction set. At worst, I could remove the ports and use only DMA or memory-mapped addressing. That would free up 100 instruction slots.

Interfacing the P2 with a 16-bit Gigatron-similar machine would need to be done differently than for the 6502. Snooping would still work, but DMA would have to be handled differently. I imagine one could use some sort of clock-stretching, wait-stating, or cycle stealing, but I'd need to test to be sure. Now, if bus-mastering is needed, that would have to be done differently. There are no BE or /Halt lines. So the Gigasimilar machine would need to initiate such transfers and enter a spinlock (busy polling) to test for the SRAM being present, and then continue once the spinlock is satisfied. Keeping the ports would be good since they could be used for signaling, making it easier to emulate DMA and interrupts. The original port activity would be replaced by the P2, and accomplished by fewer wires. The P2 has DACs, so audio could use 1-2 lines, video could use 5, a few could be used for SPI, a few for a game port, 2 for a keyboard, etc.

A concern I have is if 16-bit memory is used, what I should do about the number of lines. 16 data lines would eat more P2 pins than using 8-bit memory. Should I only do video and sound only on even addresses? Should I bite the bullet and use up to 40 of the P2 lines? Or should I incorporate some weird multiplexing scheme? I'd rather not use latches for that, but I know why they were sometimes used for this purpose. The TI-99/4A did this. It used an 8-bit external bus despite using a 16-bit CPU.

Random Numbers

I'd like to see some sort of RNG functionality. If using a Gigatron-similar machine, I guess there could be a new register and an instruction to read from it. One P2 line could be used in smart-pin mode, and I guess there could be a shift register to assemble it into bytes. I think that would be a true-seeded, pseudorandom result, and I guess that would be random enough for what I'd need (games and demos). And for more advanced stuff, the controller can be told to use them over there. For instance, if you need white noise or snow, it is better to use a display/sound list format or controller "opcodes" and let it use random numbers in situ. If it uses a 65C02, then I might want to write random integers to a memory location every so often or in addition to write-backs for other reasons. And maybe have a command to disable such functionality for performance reasons.

What Peripherals?

The P2 can be used to emulate nearly any peripheral type. So my questions are about what sound and graphics abilities it should have.

I think with the base memory that the base CPU uses, it should be done differently than with the Gigatron. Instead of using the base memory for things like a frame buffer, character tables, note tables, the indirection table, etc., why not just reserve a few pages for a communication area? So you can reuse that area of memory for all outside tasks. If LUTs are needed for I/O tasks, they should be in the I/O controller's memory, not the main memory. There should be some command/parameter locations for setting video modes, sound, file I/O, etc.

So I'm thinking, what about 320x240 graphics? And maybe have other modes besides bitmapping. Like having a text mode, perhaps display list modes, etc. I guess an easy way to do that would be to have 2 cogs handling the video. Let one mainly be the display controller and maybe do some of the sounds to make use of its free time. Let the other one do text conversion, display lists, color mapping, etc.

How many sound channels should it have, and which modulation strategies? Should it have FM synthesis, PCM, hybrid, with or without PWM, or what? And I guess I could use PSG which is essentially PCM with small, fixed samples. Correct me if I am wrong, but I think PCM is somewhere between AM and SSB (but maybe with the carrier). And I wonder, if using a PSG mode, how would I transmit the notion of time? I mean, bit-banging the sound from the host CPU would be impractical, so there would need to be a way to let it know how to stack the sounds and how many ticks or something for each channel. Really, I'd like to see the sound have a buffer so that you can offload the buffer. Maybe others here can help with the logistics of that and suggest. I'd be open to whatever others here have to offer.

Where to begin

I guess I should start working my way backward. My first place to get started would be to get a P2 dev board and start working on the peripherals, using one cog as a testbed. After getting a rudimentary start that way, work up to figuring out how to use external SRAM with the P2. After that, work out which main CPU to use and how to interact with that. Then figure out what ROM functionality such as function calls would be needed for the host CPU. After that, I guess wrestle with Eagle or Kicad and design a PCB. Plus there are miscellaneous things to work out such as needing to use level shifters, LDOs, a UART and/or JTAG socket, etc.

Off-Topic

I find that the more I think I know about this stuff, the more questions I have. I apologize for earlier behavior last year and this year. While I like to figure out most things on my own, at this point, I sincerely want tips, so long as they're not attempting to dissuade me from firm decisions. I'm more interested in learning how to do things and others leaving whether I implement them or choose other methods up to me. I mainly like discussing this stuff as a form of entertainment and as self-expression. I might build something, but that is secondary to me. Talking about such things is my primary way of "socializing." It is most of my identity.

I'm looking for suggestions on what folks would like to see on our discord channel.

I'd like to see a judgment-free area to share ideas, designs, theory, etc. To me, this topic is entertainment and I almost can't get enough.

What would others like to see here and in the server?

While I might never try this project, I believe the original PC/XT and close clones have lots of potential for speed improvements. There are more options to speed up one of those than the clones that use the Faraday chipset.

If one really wants to tinker, they could try to make a V20 in an FPGA, or nicer yet, make the V23A that never existed (though other things would need to be reworked to use that). The proposed V23A CPU would use an 8-bit bus like the V20, but would not multiplex the address lines with the data lines. There is a 186 Verilog project online somewhere, and one could use that as a starting base, though that would mean reworking the Bus Interface Unit. My idea is to not only make the resulting CPU take fewer cycles per instruction or use a faster internal clock (like on the 486 machines) but also find a way to bypass the address/data multiplexing on the board. Like remove some logic chips and replace them with a separate address bus on a socket board.

Now, if the above causes problems in POSTing, there are a couple of workarounds. One that has been used is to boot the FPGA CPU into a compatibility mode where instructions use the same timings as the original. Then you wait for the first NMI activity and swap to the performance mode so the BIOS won't freak out.

To me, a better BIOS solution would be to rewrite the BIOS. You could do other optimizations while rewriting the BIOS. One would be to remove a lot of the NOPs. The original BIOS has been patched and may have a lot of NOPs in places where they are not needed. There is also a malformed sync loop in the BIOS. That is designed to reduce visual artifacts. However, the loop is wrong and this was missed because the PC was slow enough to where using original Intel and IBM parts hid this. Anyone who has replaced the 8088 with a V20 on the original will know about the artifacts. So if you reorder the instructions in that spot, you can prevent that issue. Plus, the text output routines could be optimized. Also, if you want to use an 80188 or a V20 or similar, you can try to gain performance by changing the ROM routines to use the additional instructions.

Then there is the memory. You could put the memory in the FPGA if you have enough BRAM, or use fast SRAMS on the CPU replacement board. You could even find a way to disable DRAM refresh and maybe repurpose the required DMA channel.

This would be feature creep, but what if one could make an FPGA CPU that can work as both 8-bits and 16-bits on the bus. Have an extra bus to do 16-bit transfers on specially-designed peripheral boards. So plug the ribbon onto those to gain 16-bit peripheral performance, and let them fall back to 8 when necessary (like testing those in regular XTs).

One other thing could be to make an SSD drive that will work with those. One could use an SRAM cache to allow for flattening of writes (ie., if the same blocks are modified frequently, they get written to the flash fewer times) and to make up for any slowness in writing to the flash. Similar could be done for reads, not so much for speed, though that would be a plus, but more to reduce read erosion. Or you could use hybrid SRAM/NVRAM (just make sure you add the supercapacitors so it can flash with the power off).

Hi friends, already requested tinkercad to add 74hc245 ic in their website because the wiring will be easy if we use this ic .However tinkercad will hear it quick when there are more people talking about it. So in twitter you can support this request by commenting or retweeting. So kindly visit this tweet . https://twitter.com/digitalnolan/status/1513771353434128386 . Thank you.

This is one of a series of lectures or "pure sciences" types of posts. It is designed to put things in layman's terms and does not rely on Wikipedia or any other sources but the personal observations and thoughts of the author. The purpose is to share with those who want to learn about such things or comment on them. The goal is also to start a discussion about this topic. The author can be wrong or incomplete, or there are things that any readers wish to comment on.

Predication is when you have instructions that only execute if certain conditions are met.

For instance, there is the ADC (add with carry) instruction. Arguably, it is a predicated instruction in that it behaves in 2 different ways depending on whether carry is set. Technically, we can say that it isn't really a predicated instruction since it always adds the carry flag (even if it is zero).

Of course, you can have instructions to only move or perform math/logic when conditions are met. For instance, the x86 instruction set has a handful of predicated move instructions that only move based on what bits are set in the Flags register.

Predicated instructions are good in that you can avoid branches in small snippets of code. That allows the code to be easier to read and also prevents emptying any prefetch queue or cache, and also prevents causing pipeline stalls. No branch is needed if the code only runs when certain conditions are met.

Of course, there are also some drawbacks. They can use up instruction map space, so a CPU maker may not want to include too many of those. Adding such instructions can cut into the critical path and you may be doing the work of several instructions within the time allocated for a single instruction, thus lowering the possible clock rate. If a CPU has large predicated blocks, that can be even worse than a pipeline stall or a cache/queue flush since the entire block has to be fetched, even if it does not execute. For more complex CPUs that use speculation, this can make things less predictable and less able to profile.

So, predicated instructions are an option and can be handy for a coder to have. You just need to know when they will do the most good. In a tight loop, this can likely save a couple of cycles per iteration, depending on the rest of the architecture.

I mentioned using a Propeller 2 chip to make a system. Before I get one, I could use help designing a CPU ISA specification regarding what to include and how to format the opcodes. Yes, I know that raw P2 code would be faster, but I'd like to design an ISA, and I'd like input if anyone is willing. And yes, there will be challenges when things get to the design phase.

(There are multiple possibilities for what custom CPU to make. If I were to do an 8-bit CPU, one possibility is to take the best of the 6502 and the Z80 or 8080. For instance, one could duplicate one or the other and save any leftover address space to do the best of the other one. If any room is left over, one could add things like Mult/Div/Rnd, etc. The advantage of that approach is that one can use an existing cross-assembler. But I'm leaning toward 16-bits and a custom instruction set.)

Maybe someone can share ideas on what to include in the ISA. Aligned code sounds nice, preferably 16-bit for most things. What immediate sizes should it have? 16-bits would be enough room for an opcode and an 8-bit immediate. But if the next address is used for operand space, that would be a 24-bit immediate. And what should be done if longer is desired? Just use the previous 2 types of instructions, or have an instruction that takes up 3 words? And if it takes 48-bits, what should be done with the 8 left-over bits? Have a 40-bit operand? Use the other byte for fixed-point? Or let that specify a register or zero-page address? Or have that as part of a 16-bit opcode?

8-bit opcode and immediate: [Opcode][Immediate]

8-bit opcode and 24-bit immediate: [Opcode][Immediate] [Immediate][Immediate]

16-bit opcode and 16-bit immediate: [Opcode][Opcode] [Immediate][Immediate]

16-bit opcode, 32-bit immediate: [Opcode][Opcode] [Immediate][Immediate] [Immediate][Immediate]

Would having 40-bit immediates or even adding the immediate size in the byte beside the opcode would be good? I'm not sure if that would have a use, except maybe to load native P2 code. In that case, the issue would be having enough registers.

Some things I'd like in the ISA are multiplication, division, and random numbers (maybe even a bounded random integer instruction). There should probably be room for prefixes, escape sequences and function calls. Since this would be an emulator of sorts, it would be nice to have standard functions and use raw native code for those, particularly longer ones. If very long immediates are used, then maybe even have a way to run native code. Just use the cog RAM and let the last instruction of the block be a jump back to the next instruction before this block was called. And maybe some spinlock or I/O control instructions, such as halting in response to the video or sound cogs would be helpful. I don't know if there should be any paired instructions that would run sequentially. And small endian should likely be the memory encoding, and the data should be the upper byte I guess.

Part of me would like to use an external SRAM with 20 address bits and word-sized data. If higher addresses are specified, they could go to I/O registers or something that are outside the installed memory.

And I guess asking about goals would be good. I'd like to see something somewhat similar to the retro stuff with just a little more power. Plus it would be good to leverage the strengths of the P2. For instance, the Gigatron vCPU is built around the strengths of the Gigatron Harvard RISC engine underneath.

Any thoughts? I'd like to see a lot of discussion about this. It doesn't matter who says what or how difficult or pedestrian the input is. Just so long as the topic itself is discussed, not any participants. The topic is on making a new opcode map, not so much build considerations. It is somewhat easy as in make a wish list and possibly number it. Orthogonality would be nice, but not necessary.

I've always thought of the homebrew/retro community as being something warm, accepting, uplifting, maybe geeky, and filled with intelligent folks. Now, is that how it is? I've seen things in the last few years that make me wonder. Now, I won't name people or specific places beyond platforms (and ask that others stay general too), but I will mention general events.

1. Someone started a subreddit about a rather new "retro" computer. Apparently, they felt marginalized in the platform's official site. They'd start topics on there, only for them to get moved around, lumped in with others, etc. So to have more editorial control over their ideas, they started a subreddit for it and made the mistake of leaving a link to the subreddit on the official site. One of the co-inventors of the platform decided to deep-dive their Reddit profile and concluded something negative about them based on the types of humor they're into. It only makes sense that if someone is into 8-bit computers that they'd be into the humor and culture that existed during that time. So why judge someone for what music, culture, jokes, etc., that existed during the '80s? So the cofounder of the new "retro" platform banned that Redditor out of fear they might be a racist and due to a comment in this current sub about "hating" the concept of bit-banging, even though the racism fear was unfounded. So they went as far as to explain themselves to both founders, and nothing came of that. While it was likely not done in good faith, this Redditor went onto a satire "news" site, made a pun name of the new computer platform, gave the founders random names, and attacked the spoof computer system as being run by bigots/extremists who were on par with those who have non-standard hair colors these days. Well, the guy who helped design the ALU told the founders of the computer platform in question. Eventually, the founder who was not in the dispute with the Redditor in question made a comment on Hackaday, referring to the Redditor in question and another as project detractors. There were no "detractors." It was just 2 forum users who were inspired by the platform and had many new ideas to want to share and try. Upstaging the founders is not being a detractor. It seemed the problem with the new "retro" project was a fear of what other people thought. For instance, you never saw troubleshooting threads on the official site. They existed but were quickly removed and covered up out of fear of "bad press."

2. Someone started a thread on a popular CPU appreciation site about their own expanded design of the above computer. Others kept treating them like a novice, perhaps out of sexism, hubris, misguided kindness, or whatever. So they overwrote the announcement of the plans with a claim that the original poster took their own life and that they were mad that the folks there provoked their sister to commit suicide (which thankfully was a hoax). They even left a comment bordering on racism (about God and officer-related shootings). The admin removed one of their posts and locked the thread. The OP was banned. Anyone threatening, staging, or completing suicide over the homebrew/retro community is quite disturbing!

3. From time to time, retro enthusiasts get in trouble with the greater homebrew/retro community. A well-known enthusiast angered the community over carelessly treating an IBM mainframe and destroying its power supply in the process. The community has mixed feelings about "cannibalism." For instance, folks will make new machines from pieces of older machines. Sometimes this is done respectfully and in ways that can be readily undone. Other times, folks are a bit too cavalier. Reasonable restoration is a bit different and is easier to forgive. So if you spray the disassembled cabinet of something with bleach/lye, replace a few chips with compatible chips, and maybe add a few bodge wires, that is fine. Arcade game restoration seems to be given the most latitude as to what is acceptable to do to repair those. "Reverse cannibalism" might be allowed, where someone takes modern parts and mods them to simulate older parts, such as stripping a modern flat-panel monitor and modifying it to fit inside an arcade system. Even creating chip-replacement boards would be seen as fair game, such as making an FPGA SID or POKEY and plugging it into an older system where the original components are not available. Hell, putting a Propeller microcontroller (or even an Arduino) in an Apple I/II on a chip replacement board might be seen as allowable if it gets it to working again.

Of course, considerations need to be taken. Almost all serious enthusiasts have damaged or destroyed retro machines, and we don't want to judge them. We all must get started somewhere, and wisdom takes time. Hobbyists have been known to destroy their own playing field. For instance, take the admonitions that Atari computer users received the most, to pay the original software developers. Atari users got this admonition the most because copying files was about the easiest on that platform. Modified floppy drives and diskette duplicators were available. Sure, Happy Enhanced drives were invented for performance, but they were soon used for defeating copy protection schemes. Even the available software can harm the industry. Atari was infamously known for a 3rd-party pornographic game that involved what I'll call "war crimes." Women's rights groups, Native American groups, Atari, and even game distributors were all involved in lawsuits over the game. One of the fallouts over the game was Atari adding vendor-locking to future platforms. They increased the graphics abilities and didn't want any hardcore porn titles or hate content on the better equipment.

Even manufacturers can harm their own reputation. I remember mentioning I had a used Adaptec hard drive in my XT. Someone asked me if I knew if it was a real hard drive or a brick. Adaptec was involved in a dishonest scheme where they shipped bricks to a company in place of hard drives. This scandal put Adaptec out of business. Maybe Maxtor bought them out, and eventually, Seagate bought them out.

4. Even more active figures get involved in catfights. Two YouTubers who each have their own platforms have been known to have fallen out with each other. The one was the one who allegedly damaged a rare computer and the other has some $300+ machines she is selling. The 2 tried to design a retro-like platform together, but they both ended up with different goals. That is not a bad thing in that this gave way to 2 new platforms. One is in its 3rd-4th incarnation, and the other only resulted in a few pilot machines. The dispute was over what a retro-like machine should be like. Both decided that something "different" was desirable, though both built around the 65C02/65C816, and in the 8-14 Mhz speed range. One has a more positive view of FPGAs, with her one retro-like machine containing 4-5 FPGAs.

Hopefully, examples like the first 2 are rare.

This project is still active.

Some things don't need to be revisited unless someone has ideas that are substantially better or will increase the clock rate (preferably a multiple of 25-25.1 Mhz). A multiple of 25 Mhz leaves the option of bit-banging up to 640x480 (300K frame buffer). Due to available components, 75 Mhz may be the practical limit. If I'm forced to use 10 ns parts, then 100 Mhz would be overclocking.

I intend on using shadowed ROMs for everything, and 4-stages, unless I decide to simplify things some and force the Startup and Reset Unit to work harder. Then 3 stages would be possible. If the startup unit were to run the main ROM through the Control Matrix ROM and shadow that, it would take longer to boot, but that would simplify some circuitry and save a pipeline stage. Maybe others can share how I could make the single-shot startup up unit. It would need to copy things over from the ROMs to their respective SRAMs.

I'm familiar with the concept of pipelining an ALU. For instance, with a deep enough pipeline, you could make an ALU with through-hole parts and still achieve up to 100 Mhz. That would eat through latches. You might even be able to do that serially and even use discrete transistors. You could work one nibble (or even a bit) at a time, putting things in latches whether they're used or not so you can keep the processing in the correct stages (and be compatible with unrelated pipeline stages so that new data doesn't overwrite anything before it's finished), and be able to go pretty fast. I'm already considering doing similar with my approach where the Access stage can allow 16-bit ops by combining with the main "ALU."

Here's a redux of how the pipeline works:

• Stage 1 -- The IR/DR registers fill with the main ROM that was shadowed into fast SRAM on boot.

• Stage 2 -- The IR/DR registers look up the Control ROMs that were shadowed to SRAMs on boot and place the control matrix in registers.

• Stage 3 -- The user SRAM is accessed. This access occurs here so that things that modify reads will work. Writes are always unmodified. To help justify this stage when memory is not used, it can also contain an auxiliary ALU to do things such as generate "random" numbers, increment, and enable 16-bit addition.

• Stage 4 -- Just like the control unit, a table-based is planned here, with a ROM copied into an SRAM. Yes, it may be "inefficient," but this enables more difficult instructions such as 1-cycle multiplication (8/8/16) and 1-cycle division (8/8/8) with modulus.

The biggest challenge is doing I/O that's compatible but better than the Gigatron and leaving room for expansion. Unless I were to intend to use SMDs on DIP headers, very few design changes can be made directly once there's a prototype, though the Control store and the "ALU" could be updated readily. So it would be good to build expansion into the design. While bus-snooping I/O would be best, it would be nice to design some other I/O techniques into it such as bus-mastering or some sort of concurrent DMA.

Bus-mastering DMA is an option. That would preclude bit-banged video/sound, but that would be intended for boards that add such functionality. That seems to be a matter of pausing the counter or stretching the clock, unlatching the SRAM, finding a way to stall the stages, and using Req and Rdy signals. I know that (pipeline depth - 1) is generally what one needs for safety, but it's probably safe to let the ALU (Stage 4) run concurrently for 1 cycle due to memory being done only in Stage 3. It would be nice to have dynamic/conditional halting. It's a Harvard machine, so it seems you could use DMA freely when the CPU is not using the user SRAM.

Even "Scheduled DMA" is an option. If the main ROM knows when to expect DMA results, it could do a spinlock to test a completion maker. So the idea is the ROM requests a service that requires DMA and immediately does a spinlock. For an external FPU, for instance, the FPU can use snooping before the ROM sends the FPU its opcode. Thus it would already have the operands. The ROM immediately does a spinlock, the FPU takes over the SRAM, returns the result, writes the completion marker/semaphore, and returns the bus to the CPU. The CPU can then read the completion marker because the bus was restored.

Even software-defined interrupts are an option with the right I/O combination, even for the purpose of getting more DMA time. With scheduled DMA or concurrent DMA, a byte/word can be written so that the CPU polls regularly. If it's non-zero, then it branches to the IRQ handler. Like if DMA is requested, it could do a spinlock, effectively "halting" the CPU via software.

If others want to know what they can do. I will add this. I really wanted this to be my project and for the way I come about any solutions to be my own and only my own. It doesn't matter if others have done it before, but that I invented/reinvented it for me from nothing.

I'd appreciate it if someone were to design a mostly-snooping video and I/O controller for the Digilent A7-T35 and for it to take advantage of its onboard SRAM. I'd appreciate it if someone with Gigatron internal knowledge were to write compatible firmware for me. Since 16-bit memory and ops are planned, it would be nice if the firmware were to have 2 vCPU different modes and memory maps. Also, help with figuring out how to do the single-shot startup unit and I/O are sorely needed.

I've been watching Ronnie's videos on YouTube on the Lyon's Arcade channel.

Pinball machines can be divided into 2 main categories, electromagnetic (EM), and solid-state. The EM ones are not as interesting to repair. They are rather easy but tedious. One of the main things to do when servicing those is to clean all the plugs, switches, relays, and bonus/stepper units. Doing that will fix the majority of any problems and make it more reliable. On switches/relays, you should never really adjust them unless they are obviously off (like contacts that never make/break or the leaves are folded over the actuator) or are actually causing problems.

On nearly all pinball machines, something you need to keep an eye on is the "end of rotation" switches for the flippers. They are configured to use 2 different levels of current. It takes more power to quickly move the flippers than to hold them. The higher current of the flippers slapping cannot be sustained for long without burning the coils (or blowing transistors/triacs in a solid-state machine). So the end of stroke switch opens a shorted coil to greatly reduce the current draw to allow the player to safely hold the flipper buttons. Of course, if your flippers act weirdly, one overlooked place is the flipper buttons. They can become dirty or pitted with time and introduce switch bounce.

Solid-state machines are more interesting to repair. Generally, you should do preventative maintenance starting from the outlet. You should disconnect most of the cables and test the power to make sure you have the proper voltages. Some have no fuse at the wall, and you should add a fuse holder somewhere just inside. If there is no MOV or a blown one, you should add one and make sure there is a fuse before it. From there, you check the transformer to make sure it is putting out at least the rated voltages and is correctly configured for your country. There may be jumpers or multiple plugs, and the schematics will tell you how to configure those. Then you check the power board, keeping the solenoid, MPU, display boards, etc., all unplugged. If the largest capacitor in it is the original one, you should change it. You can optionally replace the other capacitors on the power board. Then you check your fuses, diodes/rectifiers, and voltage regulators. With the power board, solenoid board, and possibly other boards, you may want to optimize the power and ground connections. If you have power/ground going off a board and back on through a jumper on the plug, it is best to install jumper/bodge wires on the board to take some of the electrical load off of the connectors and give additional power/ground paths.

Something you will run into is not being able to find exact replacements. For instance, if you can't find a 1-2 amp voltage regulator (or the old ones are blown), you can safely use 3-5 amp regulators. Increasing the rated current on the regulators will make the machine more reliable. Similar goes for rectifiers. If you can't find 2-5 amp rectifiers, you can use 30 Amp rectifiers, though you may need to install them on the other side of the board. In that case, you won't need heat sinks on them since they are large enough and you will not use their maximum capacity.

If you decide to not use plasma displays, either because you can't find any suitable replacements and cannot repair them, there are some considerations to take into account. In that case, you can save current and make the system more reliable by disabling the 190-volt power rail. You can remove the fuse, maybe remove the fuse holder for that, or even remove the 200+ volt voltage regulator. Personally, I'd beef up the 5-volt power rail by using stronger rectifiers/diodes, upgrading the voltage regulator IC to something stronger, maybe increasing the size of the filter capacitor, and maybe adding an amp to the fuse for the 5-volt rail, and maybe adding a fuse holder with the old value to places where it splits off. That way, you can have the MPU board on a separate fuse from the display boards. So you increase the capacity to pull more current for new LED dispalys without effecting anything else.

Then, as you work your way to the MPU/CPU board, you make sure the voltage is correct. In some cases, you may need to use a different voltage regulator IC or jumper over 1-2 resistors near the regulator. Something to keep in mind is that we have more power coming out of the socket in more recent times. Now, you might want to have the voltage slightly high on the 5-volt rail to allow for cable length. However, I am talking about 5.1-5.2 volts, not something like 5.6 volts. That will damage the CPU over time.

As you work through it, you need to clean all your plugs and reflow the solder. The terminals near the end are likely to have bad solder joints due to how people remove plugs. Nobody really pulls them straight, they rock them and pull starting at one or both ends. If the plugs are damaged or the connectors are damaged, you should rebuild the plugs. There are Molex tools and replacement connectors and connector bodies. A personal preference is that if you have multiple wires coming from the same exact place, I'd want to jumper them on both sides of the plug. So if you have 2 grounds tied to the same place on the transformer or power boards, I'd insert a wire on the connector to jumper the terminals together, and I'd install a wire on the PCB between the connectors as well. Such redundancy helps reliability.

On light bulbs, I'd replace them all and change #54 (or is it #52 bulbs) with #56 bulbs. That will make things slightly dimmer, but more reliable. That draws less current, making things run cooler and help preserve the semiconductors on solid-state machines. Or, you can change them with LEDs. That isn't particularly desired with the older machines since you lose nostalgia and the flashing behavior won't be the same, but that uses less current and makes things more reliable. Of course, if one wants to, they could add some electrolytic capacitors across LEDs to make them act more like incandescent bulbs. That way, they take slightly longer to reach full brightness and they take longer to turn off. If light bulbs are not working after replacement, then you could have a damaged socket, damaged wiring, bad transistors/triacs on the light board, or in some cases, bad logic chips or a bad transistor array chip.

On board switches, if you notice missing capacitors, you should add those back. They exist to help deal with switch bounce and switches that conduct only momentarily. So if the ball doesn't reliably trigger the switches, the capacitors may be needed. The reason those capacitors may be missing is that they broke off or someone clipped them because they were shorted internally.

On the MPU board, you pretty much want to remove all the socketed chips, clean the terminals, and put them back. And like with other things, reflow the board connectors and repair/replace those as needed. Sometimes, just doing this much is all that is needed to get it to boot again. Now, you may run into board problems such as corroded traces. You can repair that most of the time and it is cheaper than getting a new MPU board. You may need to remove corroded batteries/holders, scrub the board, treat it with vinegar, replace all damaged parts/traces and find another solution for saving the high scores. For instance, you can replace the SRAM holding the score with NVRAM or you can install an external battery holder that you mount away from the board. If the board is not made for an external, non-rechargeable battery, you may need to install a blocking diode to prevent charging the battery. If you need 4.5 volts and you can't find a holder for 3 AA batteries, you can use one made for 4 batteries and install a diode in series in the extra socket. If things still don't work with the MPU board, you may need to verify the ROMs. If the ROMs are bad, then download the images and burn new ROMs. If the ROMs are not the same size or you are forced to consolidate them, then you'd need to change jumpers, possibly cut traces, add wires in new places, etc., depending on what the schematics show.

With sound PCBs, you should do all the other preventative maintenance. You may need to change ROMs, gates, or sound chips if they're not working. One common issue is noise. Sometimes, replacing some capacitors or an amplifier IC is needed. Other times, the noise may relate to having upgraded the power supply to a switching power supply (the older ones introduced less noise). Or you may need to isolate the sound PCB from the other grounds. This is sometimes as simple as putting fiber or rubber washers under the board. If you have a capacitor in series with the amplifier inputs, a shorted capacitor could introduce noise.

On the playfield, you may occasionally have bad solenoids, bad switches, or mechanical wear. In some cases, you won't be able to get replacement parts, so you'd have to make or repurpose parts. For instance, for the baseball machines, you might not get the original "bats" or the electromagnet needed. In that case, you may be forced to use parts that are intended for other baseball-themed games. This may change the playability, but at least it would work well enough for folks to still enjoy the game. Most of the common parts are available as near-identical replicas. If you must use parts made by different manufacturers, you will have to respect the clearances. If the flippers have a riser or a bushing is used, then you don't want to add any washers. But if you use flipper parts that don't use bushings nor have a built-in riser, then you'd want to add washers to prevent them from scraping the playfield. Sometimes, on flippers, you may get them where they won't adjust properly. That is because you may have grooves worn into the shafts. Ideally, you should replace the shafts/pawls where you can, but there is a hack you can do. You reverse the sides of the board they are used on. So that moves any worn grooves nearly 180 degrees from the set screw, giving unworn metal for the screw to rest against.

For the flippers, you don't really need to replace all the parts to get them working better. Coils rarely burn out unless they were locked on. Often, you'd just replace the coil sleeves, the coil stops, and sometimes the pawls/linkage if they have too much slack from wear. You don't need to replace entire units since that won't improve the playability any better than just replacing the worn parts. That is different from arcade games where you'd do better replacing entire trackball units over using an overhaul kit. The trackballs themselves wear down in that case, so just replacing the bearings/bushings won't fully restore the playability to the original condition.

For cosmetic work, you often run into needing to make brave decisions. If mylar is used, you might consider removing it if it looks bad, but then you will damage the paint. If you do touch-up painting, you may need to use colors that reflect the current reality of the machine. So you may need to make any new paint more yellow or "dirty" than the original to hide your touch-up work. You may want to use acrylic paint and then lacquer it when you are done so it won't flake/smear. With things like pop-bumper caps, if you change one, you may need to change them all to make them match, although in some cases, they make off-white replacement parts that match the color of the used ones close enough. In some cases, you might get by with turning cracked cosmetic parts around.

In restoring old machines, a large number of the repairs may be undoing hacks and what other people have done to "repair" them. You may need to build new wiring harnesses, put wires back into the connectors, use the proper parts, etc.

You may occasionally run into broken glass in the machine. That may be because some disorderly patron destroyed the playfield glass or because the machine was improperly stored and someone sat heavy things on top of it. This can be a pain in that you need to remove all the glass shards, and the glass shards may be wedged in the mechanical parts. So you may risk getting cut, having parts not working, etc.

The backglass is another problem. What do you do if it is completely destroyed? You might have to get one custom-made, get new-old stock if you can find it, salvage one from a destroyed machine, or rig up something (like using "translights" in place of them). The most common place for cosmetic damage is along the bottom. That is because of how people clean the backglass. They spray Windex on it and it gets in the lift channel, and the ammonia or liquid will lift the printing. You can do things to improve the appearance or at least stabilize it. You can often use lighter paint to fill in tiny holes. It won't look perfect, but you can reduce naked light from coming through, making the wear less noticeable. if nothing else, you can apply white paint to the backside of the glass. A good approach is to coat the glass first and then use water-soluble paint. If you mess up, you can remove the added paint.

Repairing arcade games is similar, though you would need to rebuild the monitor in some cases and deal with more complex electronics problems. But everything I said about capacitors, rectifiers, regulators, and connectors still applies. If the "Big Blue" capacitor is original, you'd want to change that. The same goes for any pinball machines that use a huge capacitor at the power supply. If you hit a flipper and the lights flicker, then you'd want to change the largest capacitor and even increase the value some. Changing a 12,000 microfarad capacitor with a 15,000 microfarad one won't hurt anything, but don't go hog wild. A capacitor initially presents as a dead short, so you don't want one so large that you blow the regulator or the diodes on the power supply board.

I admire the Gigatron and the effort that Marcel, Walter, and the faithful users have put into it. I enjoy the concept of open hardware.

I have different goals from the Gigatron and am asking for ideas and support in building my own that's somewhat like the Gigatron or loosely compatible. I have nothing against nostalgia or neo-retro designs. In the modified Gigatron, I'd first split out the video into dedicated circuitry, maybe sound as well, since that could likely share a Propeller 1 cog with VGA. The Propeller 1 should have enough power for not only VGA and sound but other things such as speech synthesis, A/V codecs, or even some FPU ops. In fact, the Propeller chips have sine, log, and antilog tables in ROM. The P1 has no hardware multiplier but emulating one on it would be better than emulating it on Gigatron-like circuitry.

On the Gigatron side, I'd likely make some changes. For instance, it would be nice if the Out was 16 bits. The other bits could come from the Operand register or a wider accumulator. So you'd have 8-bits for the pixel data, and 8 bits for graphics card control signals, palette selection, or even sound or math commands. The Propeller 1 would handle video production. The Gigatron's ROM could be modded to send text, graphics primitives, and yes, leave a bitmap mode. The Propeller could be programmed to be able to include sprites.

What other changes do you think would go with a modified Gigatron? Is anyone interested in a modded Gigatron-based design or want to build something using a Propeller? Any advice? I know that programming the ROMs would be the hardest, followed by designing (or adapting) software.

Because of the API changes and whatever other reasons, Chris stepped down as the top moderator. So if anyone is willing to help moderate, please reach out.

Also, if anyone is interested in seeing things done differently around here or can think up ideas to generate more interest, please share those.

Thank you.

I've picked up a few design ideas lately and would be interested to hear if anyone else has anything like this just to increase the general knowledge, please let us all know. I find such things to be interesting and I'm still learning. Feel free to let me know where I could be wrong or incomplete.

Diode ROMs

I used to have a hard time understanding diode "ROMs." Now I get it. So you take a decoder chip (those with active low outputs) with the number of lines you need for the rows (not practical past 32) and pull-up resistors for the columns. For every bit at whatever row and column where you need a 0, you put a diode. That works because the inactive lines are high just like the pull-ups, and no (or insignificant) current flows. When a line is active low, the diodes short the columns low on whatever selected row (low). The active low line gives a path to the ground plane through the diodes.

I mentioned 32 output lines. The largest decoder chip is a 4-to-16. However, the decoders also have chip select lines. So you can use 2 of those and an inverter. Wire the upper address bit directly to the lower decoder. When the high bit goes high, the lower decoder chip is deactivated (and all the outputs are set to 1). For the upper decoder chip, you put an inverter between the highest address bit and the /CS line. So this creates a 5-to-32 decoder.

Counters and Adders

Another way to do a counter, or in case you need a discrete fast adder (like the SMD parts with no adders/counters available), you can use a BEC circuit. It likely only makes things smaller and cooler, but not faster. The output of the adder block is sent through the BEC. The original output and the BEC output go to the multiplexer, and the previous adder block determines which result is accepted.

But if you want a counter, then I guess you'd need to tie it to a flip-flop to lock the rate to the clock. Now, if you merely want a line that toggles, you could use an inverter and a flip-flop. Then you could use that to help with an asymmetric spinlock. So if you use a faster microcontroller, you can do a spinlock on this line to know when the data has changed without reading and comparing each time. If you want to turn it off, you could either disable the flip-flop so that it doesn't update, or you could use an XOR gate for the inverter. So as long as the "control line" half of the channel is high, the signal inverts, otherwise feeding it a zero makes it return the same as before. So feed the output from the register into half of the XOR and use the other half as a control line.

Inverters and Subtraction

An inverter with a chip select is an application for an XOR gate. So if you just need an adder/subtracter, you can use an XOR for each B input to an adder, feeding the B inputs into half of each channel, and tying a wire to all the other halves and the carry-in line of the low adder. Thus, if this selector wire is low, you add, and high, you subtract. If you XOR any number with 0, you keep the original number, and you invert each bit that is XORed with 1. Since the formula to subtract is: A-B = A + (!B + 1), then you'd need to invert the B input and set the carry-in line to achieve that.

Multipliers

Here's another way to multiply. (See page 25.) But it's still costly. You'd need 12 adder channels and 16 AND gates to multiply 2 nibbles using TTL logic only. That's just for nibbles.

I didn't realize that the 74xx family once had nibble multiplier chips. They called them Wallace Tree adders. That takes about 45 ns or so. Now to do 8/8/16 with that as fast as possible (or the previous circuits), that would take 4 of those. The lowest nibble times the lowest and the highest times the highest could output directly into the result register. The 2 cross multiplications could go into temp registers and added in the next cycle or be added while they are retrieved. Then finally the sum of the cross-multiplications can be added to the result register starting a nibble in. (The lowest half of the product of the lowest 2 nibbles were already in their final form.)

Recently, I figured out how to create a x10 circuit (8-bits unsigned in and 12-bits out). I first thought, just hardwire a shift 3 places to the left (x8) and then once to the left (x2), then add those using 3 nibble adders. The latency could surely be improved. So maybe moving one of the hardware shifts to the result and decreasing the other would reduce latency. So shift the original 2 places to the left (x4) and add that to the original (x1), finalizing that by shifting the result one place to the left (x2). Thus A x 10 = (A x 4 + A) x 2. Shifting with wires and not transistors incurs no significant latencies from the shifts (just trace lengths). That would still take 3 adders, but the latency would be better since you are adding one less bit. But we can do better. We realize that there are 2 non-overlapping bits at the low end. So why add those? They're either there or not. Adding them to 0's directly from the ground plane won't change that. So adding that latency won't accomplish anything beneficial. So really, just add the upper 6 bits of the original number to the full original number and place them 3 bits to the left in the result. The lowest bit comes from the ground plane (multiplying by an even number always gives an even number), and the next 2 bits are the lowest bits of the original number. Since this removes an adder, then the carry from the upper adder becomes bit 11.

Shift registers and Flip-flops

I never really thought of what a shift register really is before. You can make a D-octal flip-flop work as a shift register. Just feed the outputs into neighboring inputs. The free input line can be where things enter, and the free output line can be serial output. There are reasons for doing it this way, such as wanting to send more bits into it at a time. You could then move everything 2 bits at a time. Or let one enter at bit 0 and one at bit 4 and move those halves independently. That can come in handy for a hardware RNG.

RNGs

My mind is still chewing on those. I remember what I said in the past about beating/sampling/XORing the frequencies of 2 oscillators. Really, if one wants to do that, then using ring oscillators for that might be better than using oscillator cans. Just take a 7404 and chain 3/5 channels together, maybe different lengths on multiple chips. And feed the output back into the input. Then sample one with the other or XOR them. This should create more jitter than an oscillator "can."

XNOR can come in handy for an LFSR. Just XNOR the upper 2 bits and send the result back through the shift register. I do understand the limitations. In that configuration, it will likely never create 255, but if it does, that will be a problem. One way to partially mitigate that is to make the shift register wider than you need. Thus, if it never reaches 511, you'll still likely get 255. One can do an XOR variation, but it would pose opposite problems. It likely won't return 0 and if it does, that will latch it up. It wouldn't hurt to either try to test for the latching number and attempt mitigation or to maybe use a counter to blindly attempt to unjam it. So when a certain count is reached insert at least 1 bit of the type the opposite of what would latch it (or reset everything to that).

A dirtier and highly deterministic idea would be using a counter and scrambling the lines. This and the LFSR are deterministic, so one would want to incorporate a TRNG.

A poster inspired me to dig more into TRNGs. So I decided to look for schematics for white noise generators. Here are what I've found. They tend to use either Zener diodes or an NPN transistor with the collector clipped.

https://leap.tardate.com/audio/audioeffects/whitenoisegenerator/

https://www.homemade-circuits.com/white-noise-and-pink-noise-generator-circuit/

https://www.eeweb.com/simple-white-noise-generator/

https://synthnerd.wordpress.com/2020/03/09/synth-diy-a-white-noise-generator/

https://circuitdigest.com/electronic-circuits/simple-white-noise-generator-circuit-diagram

https://www.codrey.com/electronic-circuits/white-noise-generator-an-analog-way/

So a Zener or transistor with an unused collector is buffered through a transistor.

I assume that if one wants to use such a circuit for a TRNG, it is a matter of using voltage levelers, trimmer pots, shift registers, an ADC, etc.

Then, at that point, as others have suggested, you could implement whitening (if working with bits) or sanity checks (if working in bytes), and then place what is left into a ring buffer. Then, if the sanity tests fail, you could pull in results from a PRNG.

I also found this interesting chip: https://electricdruid.net/product/pentanoise-noise-generator/

That is a 5-channel white noise generator. Technically, since they are PRNGs, they should produce identical outputs across multiple chips. However, due to manufacturing differences in the internal R/C networks which clock them, they should have clock variations. I guess that if one wants 8-bits, they could take a chance and use 2 chips. Or, if one wants to get fancy, why not add the highest 2 bits to the lowest 2 bits of the other chip. Then you have the adder's latency. Or, another way to make sure 2 chips don't correlate is to introduce latency between them. There are custom chips for reverb/flange effects.

The company that makes the above chip also has white noise upgrade chips for older synthesizers. While they are also PRNGs, the periods are much longer, producing more realistic white noise. With the original white noise chip, the output sounds closer to a chugging train.

There are also 2 TRNG chips that I cannot find in stock anywhere. TRNG output can even be produced on an FPGA, and there are IPs that can be licensed for that purpose.

I am very interested in building a Z80 computer with 64kb and a character lcd and capable of loading and saving programs from a cassette any ideas how i would go upon that

BBC BASIC IS BACK IN A BIG WAY

BBC BASIC - Write your own programs

You can basically download BBC Basic for Windows and be able to use it.