LX-328 - 8 Bit Digital Logic Processor with two ATmega328P MCU's

I am curious, What is it your trying to do with this, you don't say

All the logic your replicating in the 74 series TTL chips is available in the ATMEGA328's already so I'm not sure of your goal

Thanks

Peter

Not sure of it intended function overall, but if I had a guess, I would say a homemade 8-bit computer of his own design. It looks to be a more complex TTL CPU complete with his own upgrades, which wonderfully demonstrates the use of simple logic gates, buffers, a binary adder, registers, multiplexors, decoders, flip-flops, and more. 7400 IC's are very common in TTL CPU projects, so it is interesting seeing this approach to say the very least.

Jason, could you share a little more about it and it intended function(s)?

Thanks,

Cory

You are correct the NES was 8-bit.

The NTSC version had a 8-bit Microprocessor which ran at a 1.79 MHz clock rate, contained 2KiB of onboard work RAM, and 2 KiB of VRAM, 28bytes of pallette ram and 256 bytes of OAM for it's custom-made PPU (picture processing unit). The system supported up to 32 KiB of program ROM, which could be expanded by a process of bank switching. The games themselves varied in memory but the most common ran around 130-400KiB.

I suppose it could be possible to put a PPU in the circuit for NTCS output along with a 6502 CPU for analog audio.

They might be 5 volt but I think they could be controlled by a shift register. That might be fairly advanced though, it would be simpler to add an SPI based display. if there was a PPU in the circuit, some displays can take composite video as input. I could possibly create dynamic callobration where the delay value is in ram instead of rom, and could be changed by the microsecond.

The NES was a little more advanced, especially with custom made components and the time period which separates basic 8-bit computers and the NES is pretty significant.

There is not really any reason to go too complex with an 8-bit computer, however it is cool to see new ideas.

Right on, it would be a little difficult to add those components. I'll keep building and programming to see about getting the current hardware working a bit better. I might take a break for a bit to think on the programming aspect. It is a little complicating, especially with the additional hex chars so data gets routed correctly. I'll be in touch soon.

Currently, the specs are:

0xC0 Unselect Selected SPI CS

0xC1 SPI0 Chip Select

0xC2 SPI1 Chip Select

0xC3 SPI2 Chip Select

0xC4 SPI3 Chip Select

0x90 SPI0 MOSI uint8_t

0x91 SPI1 MOSI uint8_t

0x92 SPI2 MOSI uint8_t

0x93 SPI3 MOSI uint8_t

0x94 Write SRAM1 LSB Address Byte uint8_t

0x95 Write SRAM1 MSB Address Byte uint8_t

0x96 Shift Register MOSI uint8_t

0x97 LCD Display MOSI uint8_t

0xB0 SPI0 MISO uint8_t

0xB1 SPI1 MISO uint8_t

0xB2 SPI2 MISO uint8_t

0xB3 SPI3 MISO uint8_t

0xB4 reserved

0xB5 reserved

0XB6 Shift Register MISO uint8_t

0xB7 SRAM1 MISO uint8_t

0xD0 Deselects all addresses

0xD1 AddressA SRAM1 MOSI

0xD2 AddressB SRAM1 READ/WRITE

0xD3 AddressC SRAM1 Chip Select

0xD4 AddressD LCD Display RS DATA COMMAND

0x0 Set uint8_t

0x1 Set uint16_t

0x2 Set uint32_t

0x3 Set SRAM0 Address uint8_t

0x4 Set SDRAM0 Address uint32_t

0x5 Set SRAM0[Address] uint8_t

0x6 Set SDRAM0[Address] uint8_t

0x7 Increment SRAM0 Address with Wrap-Around

0x8 Increment SDRAM0 Address with Wrap-Around

0x9 Data Output uint8_t

0xA Data Input uint8_t Mode 0: Clock, Data (multiply byte by two)

0xB Data Input uint8_t Mode 1: Data, Clock

0XC Chip Select uint8_t

0xD SRAM1 Controller: 0x1 Write Data High, 0x0 Write Data Low, 0x3 Output Enabled, 0x2 not used.

0xE Toggle LCD Display RS Data/Command Pin

0xF Extended Opcode List

0xF0 Increment SRAM1 Offset with Wrap-Around

0xF1 Increment SRAM1 Segment with Wrap-Around

And tons more to come.

It is always good to take a break once in awhile. Programming can get pretty stressful at times and there is no reason to overwork yourself. : )

I spent the day rewiring the board twisting groups of wires together into braids to make the appearance a little nicer. It also helped to make the board easier to get around. I placed the MCU's on the SPI bus so now the MCU's can be selected in ISP mode directly. I might hand it a boot option where users can select which device they'd like to boot from, like SPI0-SPI3, EEPOM0-EEPROM1(MCU EEPROM). This might come in handy being able to select the MCU's to read and write from EEPROM contents without disturbing each MCU's flash. I can give them the option to Save EEPROM so upgrading flash won't format the EEPROM data. There might not be a need to update flash firmware, but with access to the MCU flash, some users might be enticed to update but it could make the board inoperable. For this, I can create forbidden opcodes unless the user is in some sort of Administrator mode. This could be accomplished by a boolean, IsAdmin. If IsAdmn == true.... I'll be creating the command prompt over the next few days. There will be 6 devices the user can boot from, any of the SPI loading from 0x0000 or from either MCU EEPROM. With a list of opcode instructions available to the user, they can freely develop their own operating system contolling data flow. The other thing is you could still read and write to the boot device. Perhaps the bootloader could be 256 or 512 bytes. 1 or 2 pages in the boot section of the device. Maybe I could place a byte at the end of EEPROM in one of the MCU's that shows which device to boot from, and how many 256 byte pages the bootloader is since it can be written to 100,000 times. High 4 bits show which device to boot from, and Low 4 bits show how many pages the bootloader is. Guess it could have up to 16 pages of 256 bytes available in each page.

I prefer a nice appearance myself, not only for as you mentioned, making it easy to maneuver, but also because I like ascetics in keeping a clean and crisp project. Appearance is not always everything, but it really does help.

I like your idea of adding a boot option allowing the user to select which device they would like to boot from. I like having options rather than just being subjected to a single thing, if options are available. This is why if you use any one of my SD Cards for my Raspberry Pi's, you will find at least two OS options.. that is unless what I am working on requires only one, such as the Raspberry Pi arcade project I am working on.

Was working on a control panel in Visual Basic.Net today to access all memories on the board. I'll be handing it an automated and a manual mode where manual mode would allow controlling the board through data entry entering hex chars, and the automated mode would operate automatically incrementing stack and instruction pointers. One more week and the majority should be finished. There's an SPI based display headed this way so I'll definitely integrate that into one of the SPI channels.

Oh. This gives me an idea with what I am playing with! Windows programming hardware on remote boards. Love it.

Thanks,

Clem

Yay! I'm very excited, but I've been controlling it in real time entering hex chars through the keyboard. With the hardware working, I can go ahead and create a way to increment and retrieve data from flash or either of the MCU's EEPROM. Also working to develop some sort of command prompt, but I'll probably have to make some custom peripherals for data entry if the board is used in standalone automated mode.

The board should give beginners a chance to understand the 7400 series logic with the addition of SPI-based storage solutions.

Creating a user guide might take about a week, but I'll cover everything from running the board in real time using the opcodes, to creating apps that run automatically from any of the storage devices on the board. Currently there are 6 non-volatile memories, but the SPI-Flash also has two 256 byte buffers a piece available to the user.

Still not sure if there is a way to access MCU SRAM in ISP programming mode, but this is how I'll be having it access Flash and EEPROM.

Perhaps the drive labels could correspond with the devices, SPI0:\ EEPROM0:\ etc.

We'll get there, it'll take about a week to finish a bootloader but the user guide will even cover this.

For updating MCU Flash, I'll just have the VB.Net app handle ISP programming in circuit through USB CDC.

No more wondering how to get code onto the MCU's that are blank and don't have their own bootloaders.

I spent a day or two understanding how bytes are written to the ATmega328P Flash, 2 bytes per address.

Hex files show one byte per address, but the loading address is the first address shown in the hex file.

From there, I can have the VB.Net app upload data into either of the MCU's.

I also made them removable so they can be replaced and reprogrammed very quickly.

Yay! I'm very excited, but I've been controlling it in real time entering hex chars through the keyboard. With the hardware working, I can go ahead and create a way to increment and retrieve data from flash or either of the MCU's EEPROM. Also working to develop some sort of command prompt, but I'll probably have to make some custom peripherals for data entry if the board is used in standalone automated mode.

The board should give beginners a chance to understand the 7400 series logic with the addition of SPI-based storage solutions.

Creating a user guide might take about a week, but I'll cover everything from running the board in real time using the opcodes, to creating apps that run automatically from any of the storage devices on the board. Currently there are 6 non-volatile memories, but the SPI-Flash also has two 256 byte buffers a piece available to the user.

Still not sure if there is a way to access MCU SRAM in ISP programming mode, but this is how I'll be having it access Flash and EEPROM.

Perhaps the drive labels could correspond with the devices, SPI0:\ EEPROM0:\ etc.

We'll get there, it'll take about a week to finish a bootloader but the user guide will even cover this.

For updating MCU Flash, I'll just have the VB.Net app handle ISP programming in circuit through USB CDC.

No more wondering how to get code onto the MCU's that are blank and don't have their own bootloaders.

I spent a day or two understanding how bytes are written to the ATmega328P Flash, 2 bytes per address.

Hex files show one byte per address, but the loading address is the first address shown in the hex file.

From there, I can have the VB.Net app upload data into either of the MCU's.

I also made them removable so they can be replaced and reprogrammed very quickly.

A new SPI display? Please do post a new picture after this has been integrated. I would love to see new changes as they are implemented.

Good idea on making the MSU's removable.

I have had a few ATmega's and even a couple 555 timers burn out on me. Having those DIP sockets really do prevent the tedious work of having to de-solder when this happens.

As I mentioned before, boards like this are great educational pieces when learning not only 7400, but basic logic in general.