Advice needed on SBC

[Dr Jefyll]

The port pins are capable of functioning either as inputs or as outputs. The default state (after reset) is for them to be inputs. (And most 6522's have pullups that cause inputs to go high unless driven low.)

Sounds like you want the pins to be outputs, but have neglected to set them as such. To do so you need to write to the Data Direction Register. The data sheet has the details you need. Have fun!

-- Jeff

[GARTHWILSON]

A little more detail: You'll need to write to DDRA or DDRB (data-direction register A or B) of the VIA, with a '1' in each bit that you want to be an output, and a '0' in each bit that you want to be an input. You wouldn't want simply writing to port A or B to automatically make it outputs, so they made it so input bits still remain as inputs when you write to the port.

I have only had two problems with the VIA. One is the mode-011 shift-register operation bug (explained in Tip #8 in my "Tip of the Day" column), which is something that won't affect most users but there is a way around it. The other was in getting T1 (timer 1) running in free-run mode, explained in Tip #9, something that was not spelled out in the data sheet and we got it going only after a Rockwell applications engineer faxed us an ap. note in about 1987. Aside from these, the data sheet is very complete. Everything you need is there. It takes time to go through and learn it; but doing things per the data sheet, I have never had any problem with it (with the two exceptions above).

[Floopy]

Well that's what I was missing. I was wondering why the datasheet kept talking about DDRA and DDRB. Also took some time to figure out that you can set whether a port is an input or an output individually.

I made a small routine that turns the output on and off. Although the delay is too short to blink an LED. So no blinky yet.

Anyone have recommendations for writing programs? I've just been writing it on paper, converting it all to hexadecimal, and then typing it up in a hex editor. I make a lot of mistakes especially when typing and converting to hexadecimal. It worked more or less when I was doing this on the VIC-20, but now that the programs are lengthier it's harder to manage.

Thanks for the resources. I wouldn't be here without all of you!

[Chromatix]

You could use a text editor and an assembler like (most of) the rest of us. I'm using as65, from the cc65 compiler suite. Others have different preferences.

[GARTHWILSON]

Floopy wrote:

Well that's what I was missing. I was wondering why the datasheet kept talking about DDRA and DDRB. Also took some time to figure out that you can set whether a port is an input or an output individually.

It looks like you've got it now, but just to be sure: You can set not only the individual port (port A or port B) to be input or output, but individual bits within the port. For example, you might have bits 0, 1, 3, 4, and 6 be outputs, and have 2, 5, and 7 be inputs. Don't overlook CA1, CA2, CB1, and CB2 either. They have a lot of functions besides just parallel-port handshaking.

Quote:

Anyone have recommendations for writing programs? I've just been writing it on paper, converting it all to hexadecimal, and then typing it up in a hex editor. I make a lot of mistakes especially when typing and converting to hexadecimal. It worked more or less when I was doing this on the VIC-20, but now that the programs are lengthier it's harder to manage.

That's where many of us started, and I think it's a good place to start. It lays a foundation of understanding that's hard to get for people who start out with more up-scale tools.

There's a list of assemblers, mostly free, at http://wilsonminesco.com/links.html#assem, and also on this site at http://6502.org/tools/asm/ . I like, and would recommend, the C32 assembler I use; but if you really need it to be free, one I have not used but looks really good is As65, written by our own Andrew Jacobs (forum name BitWise).

Chromatix wrote:

You could use a text editor and an assembler like (most of) the rest of us. I'm using as65, from the cc65 compiler suite. Others have different preferences.

Should that say ca65 (instead of as65)? CA65 is part of the CC65 suite.

[BigDumbDinosaur]

Floopy wrote:

Anyone have recommendations for writing programs?

The Kowalski 65C02 editor/assembler/simulator is what I use.

[Chromatix]

Well there you see - there's so many options for assemblers, it's easy to get their names mixed up. Just pick one and try it.

[Dr Jefyll]

Floopy wrote:

I've just been writing it on paper, converting it all to hexadecimal, and then typing it up in a hex editor.

I agree with Garth -- this *is* the best way to start. That's because you learn to see the world as the 6502 sees it -- which is to say as an endless series of bytes; NOT as tidy, commented, human-readable source code.

While you're mucking around down in the basement of how things work, I suggest you make a habit of referring to the cycle by cycle behavior that's documented in Appendix A of the MCS 6500 Family Hardware Manual. Seriously -- spend some time with this! It will shine a light on what else the CPU is doing. Yes it fetches the code -- those bytes you laboriously entered -- but how and when it does so is important. Plus, there's other stuff going on (such as the data reads and data writes for the instructions you coded). Recommended! You can find that manual here.

-- Jeff

[Floopy]

Thanks for all of the resources.

Finally got an LED to blink. I just need to improve the program by using subroutines. It's amazing how much you can do with so little. I had never realized how many instructions there where.

Can you put a subroutine within a subroutine?

[GARTHWILSON]

Floopy wrote:

Can you put a subroutine within a subroutine?

Nested subroutines? Sure. You can nest them as many levels deep as you have stack space to store the return addresses and anything else getting stored there, which is way more than you'll probably ever need. (There are some uses which could benefit from a lot more stack space, but like I said most uses will find the 6502's stack space to be much bigger than necessary.) See my stacks treatise at http://wilsonminesco.com/stacks/ . It starts with the very basics and works its way up, layering knowledge upon knowledge. Go as far as you feel ready for.

[Floopy]

I got tired of burning endless amounts of EPROMs. I also wanted a way of testing my programs without having to carry 10EPROMs + UV eraser. I thought about EEPROMs, but they are expensive. I do have a few 29F010 flash chips. I made an adapter and now it simplifies programming a lot!

I also took the time to build a second board that fixed the issues the first one had (there is a bodge of wires under it, but it's hidden).

[Mike Naberezny]

Floopy wrote:

I got tired of burning endless amounts of EPROMs. I also wanted a way of testing my programs without having to carry 10EPROMs + UV eraser. I thought about EEPROMs, but they are expensive. I do have a few 29F010 flash chips. I made an adapter and now it simplifies programming a lot!

When Daryl designed his SBC-2 board, he put in jumpers to allow either an EPROM or an EEPROM to be used. I had always used UV EPROMs but I tried an EEPROM for the first time when I built the SBC-2. I remember thinking how great it was to not need the UV erase step.

At this point, I've been doing all development on an EPROM emulator for years. Not having to unplug anything is even more convenient; almost like programming a modern microcontroller. Now I only burn real chips every once in a while. I usually use UV EPROMs since I still have a bunch of them.

Floopy wrote:

I also took the time to build a second board that fixed the issues the first one had (there is a bodge of wires under it, but it's hidden).

Your board looks good. That's a nice nod to the forum members in the silkscreen!

[1024MAK]

The other way of developing is to design the system to have a larger CMOS SRAM. The glue logic allows the SRAM to shadow the EPROM/EEROM area (reads come from EPROM/EEROM, but writes go to SRAM), or to replace the EPROM/EEROM area in the memory map via bank switching.

This then allows a simple program in the EPROM/EEROM to download a development version of your ROM code to the shadow RAM. Then copy a short routine to normal RAM. This short routine switches out the EPROM/EEPROM and switches the shadow RAM to read mode (so the EPROM/EEPROM is disabled). If you want, you can also disable writes to the shadow RAM, so that it has some protection in case a crashed system randomly tries to write to this area of RAM. Once the shadow RAM is switched in, control is passed to the code in this shadow RAM area.

Of course, this does make the glue logic more complex. It also requires that there is a communication link between the system and another computer so that code can be downloaded.

Mark

[BigDumbDinosaur]

Mike Naberezny wrote:

I had always used UV EPROMs but I tried an EEPROM for the first time when I built the SBC-2.

I continue to use AMD 27C256 EPROMs, which are rated at 55ns, as no EEPROM will keep up with my POC V1 unit at 12.5 MHz. Atmel (aka Microchip) continues to produce an OTP version of the 27C256 in a 45ns rating.

[BigDumbDinosaur]

1024MAK wrote:

The other way of developing is to design the system to have a larger CMOS SRAM. The glue logic allows the SRAM to shadow the EPROM/EEROM area (reads come from EPROM/EEROM, but writes go to SRAM), or to replace the EPROM/EEROM area in the memory map via bank switching....It also requires that there is a communication link between the system and another computer so that code can be downloaded.

That's where a high speed serial link comes in.