Stunning Motorola 68000 system made by Computer System Associates USA circa 1984

[Bruce Tomlin]

I've been looking at the board pictures to make a sort of netlist, and I finally got my first good look at that KiCad partial schematic by opening it in KiCad. (Whatever you used to make PDFs made really broken ones that drove the PDF handling in OS X nuts, as in the "trying to allocate every byte of memory in the system" kind of nuts.)

So a few more things:
- the segment pins may actually be on P0
- write_segments might be possible to write as "P0 = data" instead of messing with each bit separately
- delay_ms should probably instead be a function that does a bunch of 1ms delays, and checks for comm input in between them (do not busy-wait for more bytes when you get comm data, just update variables and move along)
- main() would clear display_mem first, then a while(1) loop to call scan_display and then scan_keypad and then check what's up with the comm stuff

 

[Pt68k5]

P0 are the data bits connected to thru U2 on the serial board as a buffer, then U2 is feed to the 10 74s373 U1 thru U10 on the display board
P2 outputs P2.0 thru P2.3 connects to U11 the 74154 4 to 16 decoder which is connected to the 10 latches (74s373)
P2 outputs P2.4 thru P2.6 are connected to U12 the 74ls138 3 to 8 decoder which turns on and off the four transistor driverd Q1 thru Q4.
DS1 thru DS4 and DS5 thru DS8 are the top row of displays and should display the startup message (68000 UP)
I have a lot more to learn to be able to write different functions and then call them.

The hex keypad is connected to both P1.0, P1.1, P1.2, P1.3, P1.4 and P3.4, P3.5, P3.6, P3.7

I will keep working on the decoding my first goal is to get the top 8 displays showing the correct data from the serial data.

Thanks Tony

 

[Bruce Tomlin]

The thing about the display board is you don't just get a few of the displays working, you get them ALL working at the same time because there is nothing special about one display vs another. And I could barely see the "P0=" in your code because it wasn't set aside as a subroutine that said "hey, I am writing some segments here". Making the "P0=" part into a subroutine that just does "P0=data" is almost cost-free in terms of program code, but has a big result in terms of a human being able to understand what is happening, because now you've given it a name. It's the same with writing the group and digit selects. It's also usually a lot less to type every time.

A builder doesn't throw a pile of wood on the ground and start randomly nailing things together. It's like instead of saying "a door goes here", you say "make a rectangle of some planks, then put some plywood on both sides, and some hinges too" every time you want a door. "Let me just get these two doors working and then I can start building some walls!" You don't put random wood together, you make a bunch of identical doors and say "a door goes here", not "put a rectangle and some plywood here".

You did have a subroutine for segments, but it was called "SetDisplay" even though it didn't set anything, which is basically lying to the poor sap trying to read the code. In fact it was trying to convert hex data from the comms into 7-segment display patterns for two digits, and that isn't even right. Each hex byte is half the segments for a digit, and you're not even handling A-F properly. No amount of poking at the rest of the display code will fix these fundamental problems. You are banging your head on a dead end. The code you've been picking at is not worth wasting any more time on.

You're mixing up decoding the serial data with writing data to the display. The part that handles the serial data has the responsibility to turn the two hex bytes it receives into binary, then put it in the display memory. The display code should not know anything about the comm port or the protocol, and the comm port code should not know what P0 and P2 are. That's called encapsulation, and it's an important part of designing a program.

Anytime you make something bigger than a one-trick Arduino sketch, you have to make one thing work at a time. If you throw a bunch of code together, it's all mud until you get each part working, and you can't know if your problem is in the other thing you haven't worked on yet. Basically your code is a ball of mud that you're kicking around like a football, and I can tell that you're new at this programming thing.

I think you should ignore the serial port and keypad for now and focus on the display board first. Decide on what a display should look like, set up display_mem with constant values that you know what they should be (including the individual LEDs), then make that work. If you see a display but it's all wrong, try changing some of display_mem first, and see what that does.

Other than the segment data being on P0 instead of P1, there should be nothing fundamentally wrong with what I posted in the previous message. But do take out all that "sbit seg_*" stuff and replace write_segments with:

void write_segments(char data)
{
  P0 = data;
}

I was just being cautious about things I wasn't sure about. Also pre-initialize display_mem like this to set up a test pattern (yes that data should look familiar):

char display_mem[4*10] = {
  0x3f,0x06,0x5b,0x4f,0x66,0x6d,0x7d,0x07,0x7f,0x6f,
  0x3f,0x06,0x5b,0x4f,0x66,0x6d,0x7d,0x07,0x7f,0x6f,
  0x3f,0x06,0x5b,0x4f,0x66,0x6d,0x7d,0x07,0x7f,0x6f,
  0x3f,0x06,0x5b,0x4f,0x66,0x6d,0x7d,0x07,0x7f,0x6f,
};

 

[gottahack]

If anyone wants it, I wrote code for the microcontroller on the display board, but I wrote it for an ATmega8515-16PU which is pin-compatible with the original 8751. It requires a board mod because the Reset pin on the AVR has the level sense reversed, but Pt68k5 says it is working with his trainer.