Page 6 of 6

true self-modifying code

Posted: 03 Feb 2020, 08:11
by ECL
PurpleGirl wrote:
19 Dec 2019, 08:41
The only advantage of this approach would be the ability to arbitrarily assign opcodes
... with the added bonus of driving WozMon debuggers crazy, but not necessarily emulators.

true self-modifying code is always cool to run, no need for FPGA. It would mean code obfuscation beyond any measure! Transmeta code-morpher, here we come! Watch your back, Linus Torvalds! :P

New Reddit Sub

Posted: 11 Feb 2020, 06:48
by PurpleGirl
Since everything I posted is jumbled up with unrelated things all merged together, I just created a new Reddit sub and I may copy everything I posted in its own thread. That might be the best since I can then get my thoughts together. And if others want to copy in their replies from here, that would be good, if not, I could use the quote feature.

The video card ideas are not the same as the opcode ideas or the multicore ideas, so I will likely look for another way to host all that to be able to keep them all separate. The good part will be that I'll have my thoughts better formulated.

Re: dual core Gigatron CPU

Posted: 11 Feb 2020, 17:21
by GigaMike
I agree with the separation of the ideas because they probably will have different solutions. But why not continue to use this forum instead of yet another place?

Re: dual core Gigatron CPU

Posted: 11 Feb 2020, 23:09
by PurpleGirl
GigaMike wrote:
11 Feb 2020, 17:21
I agree with the separation of the ideas because they probably will have different solutions. But why not continue to use this forum instead of yet another place?
I and others initially put everything in separate threads. The only way I can control the integrity, quality and coherence of what I post is to have control of the hosting space. Whenever you use someone else's forum or space, you are at their mercy. I'm not the only one impacted. This thread was started mainly for video separation. I started one that had nothing to do with this on opcodes, and someone else started the multi-core thing. But then all the other threads were merged into this one.

I appreciate the work done here, and part of the reason for trying to find other space is out of respect.

Something interesting is that the original Gigatron sub is banned on Reddit. It might have been related to a cartoon character of that name. If I wanted, I could request that it be unbanned and handed to me.

extra hardware for expansion port

Posted: 13 Feb 2020, 09:49
by ECL
this stuff is definitely hi-res:

Send video/audio over HDMI on an FPGA such as: ... pga-board/

dual core Gigatron CPU

Posted: 13 Feb 2020, 11:15
by ECL
I guess "dual core Gigatron CPU" was initially my headline; well, I understand the desire of the forum owners to counteract fragmentation of design ideas. But also I agree that undue re-editing of articles by superiors may not sit well with some. Frankly, I dislike reddit for their very heavy interventions as a matter of policy. Even HackerNews is not ideal.

Re: dual core Gigatron CPU

Posted: 14 Feb 2020, 19:02
by PurpleGirl
I am not sure if I want to build anything at this point, TBH, though I might want to try to learn Verilog. The momentum I was building sort of died and the different threads with different but overlapping ideas helped to build it. And I get what you are saying, but jumbling up different ideas doesn't help. And on Reddit, it isn't admins who mess with things, but moderators, and since I'm the mod and will hopefully not be in TOS violation, I should be able to have separate threads or even wiki pages for my ideas. I understand the moderator drama over there.

As for me, I learn best by posting/speaking, since that forces me to research, and others will throw in ideas. If I want to take on a similar project, I will need to find an environment that is conducive to that.

Video separation and dual core Gigatron CPU

Posted: 27 Feb 2020, 16:02
by PurpleGirl
I'm still trying to figure out how to split the video from the CPU on the Gigatron or a similar homebrew design. The easiest parts are generating the syncs and doing D/A conversion on the video signal. I don't know how to build the rest of the controller, how to offload the video generation onto hardware other than the CPU. I guess I'd have to add different modes. Text mode would be good in that you could only send ASCII and the video hardware does the rest. That would take a processor and ROM. Dedicated RAM would be good so it can hold an entire frame.

But even with dedicated RAM, I'd still have the issue of being able to update the video RAM and trying to read it at the same time. One method that has been done is to have separate "slots" in the cycle time. So one device is guaranteed access half the time, and another device is guaranteed access the other half. So any transfer takes 2 cycles. I guess one could double the clock and use registers to buffer things and the video side to where 12.5 Mhz would still allow for a pixel clock of 6.25 Mhz without reducing screen size.

An idea came to mind. I wonder how helpful a Propeller chip would be. It is an 80 Mhz, 32-bit, 8-core RISC CPU with built-in VGA-generation abilities, and available in a 40-pin DIP. It has 32 I/O lines. It has PLL circuits and a few advanced math tables in it's internal ROM. It has 2k of RAM per "cog" and can address 32K RAM and 32K ROM from its hub, with 2 timers and VGA-generation (and composite) circuitry in each cog. If you use the internal VGA circuitry, the format is exactly opposite the Gigatron, with the first 2 bits being the syncs, then the 2 blue bits, then the 2 green bits, and then the 2 red bits. The I/O lines can only be used in one direction at a time. And if more quality is desired, such as 4-5 bits per channel, I don't see why one couldn't ignore the internal VGA-generation and bit-bang with one of these, since the Propeller is completely software-driven. Or one could probably output in 24-bit and use TTL logic for multiplexing into 3 8-bit signal streams. It is just a matter of programming a ROM for it.

However, on the Propeller 1, most native instructions take 4 cycles minimum, and maybe some taking up to 7, with a worst-case scenario of maybe 22-23 cycles. The reason for the worst-case scenario is due to drum access to the hub memory and the hub being clocked at 1/2 the cogs. So if you miss the hub slot by even a half hub cycle, you have to wait up to 15 more cycles. Propeller 1 only has the 32 I/O lines, a connection for serial memory, power, and a serial connection to program it externally. Four of the wires on the P1 are borrowed for a serial boot device, but they are free for use once it boots.

There is a Propeller 2 in the works, with engineering boards, samples, and FPGA code available. It is at least 5 times as fast as the Propeller 1 and has 64 I/O pins. It can clock to at least 200 Mhz. It is rated for 180 Mhz and one claimed they were able to get it to do 360 Mhz. So 200 Mhz is 2.5 times the throughput. It executes at least 1 instruction every 2 clock cycles per cog. It does have 100 pins, with 64 being for data and most of the rest being for power. They added more power connectors for stability reasons and perhaps to allow for 1.6 volts internal power and 3.3 volts for I/O.


Now this gives me a couple of other ideas. For one, why not use the Propeller like a VIA? It has a total of 32-bits of I/O lines that can be compartmentalized any way you want. For instance, it could take over not only Out, but X-Out as well. The advantage of it doing audio would be that it could hold notes or play music during the screen drawing. If one wanted to use the Propeller 2, it has 64 I/O lines and at least 8 cores, so it could be a good I/O controller for all the I/O. The Propeller 2 even has IRQs, though with at least 8 cores, some can be dedicated to polling, bit-banging, etc., with autonomous timers, triggers, and streaming circuitry to make that even easier.

The Propeller could even be used as a coprocessor. The P1 could be programmed as an emulator while the P2 would likely have most of what is needed natively.

Another idea would be to use the P2 as a video controller and DMA controller. A halt line could be added to the Gigatron, and while DMA control would not be needed for video since the P2 could be the GPU, DMA could be used for data storage/loading.

I am just throwing this out there, since for the vintage folks, a Propeller would be cheating. However, some vintage folks are willing to use a Propeller in places where original chips are not available, such as in the Apple 1 DIY kit. Its video controller is not available so a Propeller 1 and a tiny serial ROM for it does make a suitable replacement. The ROM configures the P1 on boot and allows it to emulate whatever hardware.

I do wonder if the Propeller could have some uses in the Atari computers. For instance, if it can replace the GTIA, it could provide VGA support.