Vulcan-74 - A 6502 Powered Retro MegaProject

[Oneironaut]

Update -> The 6502 is up and running!!
This is a milestone for this project, as I have exceeded every original goal.

For the last few days on my daily hour commute, I have been thinking about how I should approach my 6502 migration and learning curve, and eventually came up with the plan to start with one of the many good basic web tutorials available, and eventually get an LED to flash from my IO decoding scheme.

I then remembered that this is totally not my style, and within an hour had the AVR yanked and the 6502 completely wired up to SRAM and the 80 IO decoding logic based on my napkin sketch!

From there I wrote a Visual Studio program that would take the HEXDump from the amazing Easy6502 site, and convert it into a .DC.B (byte file) that I could load into the AVR that preloads the 6502 program memory. I then wrote some 6502 code to do basic control tests, added it to the AVR, which allows the AVR to bootstrap the SRAM while holding BE and RS low. From there, the AVR goes invisible and allows the 6502 to take over. Besides the reset vectors, the rest of the program code lives at address 768 and higher, with my 80 IO lines mapped at address 512.

With the 6502 clocked at a very conservative 4MHz, everything worked perfectly on the first power up!

The result was the Vulcan-74 Video System swapping the Live and Back Buffers at 60 frames per second while drawing a few pixels directly to the Video Memory.
If one command (IO toggle) works, then they certainly all work!

I had figured that getting the 6502 working would have been one of the more challenging parts of this project, but so far it seems otherwise!
Once I add the faster 10ns program memory (using 15ns now), I will up the clock to 20MHz and see if it all holds together. 16MHz is my fallback.

So far, the most challenging parts of this project have been the Sprite Transparency Logic and the high speed section of the PlayField Generator.
The Audio Generator will also be very easy, as there are no extreme high speed timing issues to deal with.

The boot section will probably be somewhat of a challenge, as one of the requirements is to drive data from a large Serial Flash Memory (External Game Cartridge) to the 6502 Program Memory using only logic. There will be some Serial <-> Parallel magic to deal with when streaming data and sending commands to the Serial Flash.

Anyhow, I am all hyped about seeing the 6502 in the Captain's chair, and will do a few more tests before I clean up the mess of wires coming from the 6502.
I am now deciding on a proper assembler to use, and will begin making the "Kernal", which will be a collection of routines to drive the Vulcan Hardware.
Looks like the WDC toolchain is the most full featured offering so far.

The 65C02 is a great processor to use! Super easy to program and connect to the real world.
I can see this being a very fun platform to program.

Cheers!
Radical Brad

[BigEd]

Great work!

[BigDumbDinosaur]

Oneironaut wrote:

Update -> The 6502 is up and running!!

Is that actually a 65C02 perchance?

[Oneironaut]

Why yes, it certainly is!

viewtopic.php?f=4&t=3329&start=165#p40933

As part of my original "Rules", all ICs have to be actively manufactured and readily available, so 65C02 is the only option.
Every other IC used (7400 logic ICs and SRAM) has multiple manufactures and distributors.
In other words, anyone crazy enough to want to build one can easily find parts now and 10 years form now!
When I get all the build docs up on Vulcan74.com, I will also maintain an active suppliers list.

Brad

BigDumbDinosaur wrote:

Oneironaut wrote:

Update -> The 6502 is up and running!!

Is that actually a 65C02 perchance?

[jmp(FFFA)]

Great work Brad. Very impressive how far you've come in such a short time.

If you're an old school programmer comfortable with Makefiles and the command line, I'd recommend taking a look at 64tass (http://sourceforge.net/projects/tass64/). Seems popular among some of the oldtimers here and in the little time I've been using it, I can see why. Fully supports the 65c02 as well and comes with solid documentation. I've been using it with Cygwin myself, but it runs fine on Linux too if that's your cup of tea.

WDC charges for their development tools and with so many good free choices out there (e.g. http://6502.org/tools/asm/) I personally would look elsewhere.

Edit: Fixed 64tass URL so it works...

[BigDumbDinosaur]

jmp(FFFA) wrote:

If you're an old school programmer comfortable with Makefiles and the command line, I'd recommend taking a look at 64tass (http://sourceforge.net/projects/tass64/).

That link is broken, as are several others on the 6502.org tools page.

Quote:

WDC charges for their development tools and with so many good free choices out there (e.g. http://6502.org/tools/asm/) I personally would look elsewhere.

I purchased WDC's development package some time ago in hopes of getting lots of use from it, but ended up setting it aside. Although the assembler and C compiler work fine, with the latter emitting reasonably succinct code, I found that the overall package was cumbersome to use, especially in rapid assemble, test, debug cycles of the type in which I often engage. I have continued to develop in the Kowalski simulator despite its own idiosyncrasies, as I can edit, assemble and transmit object code to my POC unit with little effort.

[jmp(FFFA)]

BigDumbDinosaur wrote:

jmp(FFFA) wrote:

That link is broken, as are several others on the 6502.org tools page.

So strange. I brought up that web page in my browser a couple of hours ago. Oh wait -- there is a closing parenthesis at the end of the URL that doesn't belong there. Sorry 'bout that. Fixing now.

I still have plans to try Mike Kowalski's system out as well, as soon as I get a bit further with the hardware...

[BigEd]

(If you find errors or omissions on the site, please send a PM or email or submit a pull request on github. Mike's email is at the foot of every page!)

[Oneironaut]

Thanks for all of the suggestions.
I have an odd style of coding, so my requirements (or lack-of), in order of importance are...

1) Single button HEX file.
By that I mean going from code to a data file with no messing around. Since I have created a loading system for my Flash Memory based "Cartridges", I want the toolchain to have as few steps as possible. Code, Compile, Send. I don't want to have to use multiple programs (especially command line) just to go from code to HEX file. AVR32 did this to me with AVRStudio + FLIP, so I refuse to use it.

2) No C compiler, Debugger, or Wizards! I want the ultimate MINIMAL IDE.
I have zero interest in C for this project, and I NEVER use debuggers / simulators / test-bench, etc. I code, compile, and then fix what's wrong the hard way... by looking at the code. In all my years of writing very complex assembly for AVR, PIC, ARM, and HDL for CPLD and FPGA, I have never used a debugger and do not intend to. I also have a rule to NEVER use code that I didn't write, so I don't want a compiler that holds my hand with suggested bloat code, or links to volumes of pre-made code that will ruin the challenge. I can't imagine that the 6502 tools are like this, but every other toolchain I use seems to be going down this rabbit hole! This continual dumbing-down of electronics and coding is what drove me to build this monstrosity in the first place!

3) Clean Windows IDE.
I like a huge window for coding, with code that will highlight properly. Comments should be one color, data would be another color, etc. Scrolling should not be clunky on large files, because I write very long code. I will have no problem writing 64K worth of pure assembly. Atmel Studio (Visual studio based) is almost perfect this way except that scrolling gets clunky when your code starts to exceed 500 lines or so. That pisses me off to no end.

So if anyone has a suggestion for an IDE that will do nothing but display nice colored code for me and then allow a single click to a .HEX file, that would be great!

I am thinking it may be easier to simply write this myself as an extension to my Vulcan-74 Graphics and Sound converter. All the compiler really needs to do is insert addresses for labels and turn instructions into numbers. Seems easy enough!

For now I will continue with this one...

https://skilldrick.github.io/easy6502/#first-program

I have coded a simple program in Visual Studio that captures the text generated by the "HexDump" button on the web page which turns this...

Code: Select all

0600: 20 06 06 20 38 06 20 0d 06 20 2a 06 60 a9 02 85 
0610: 02 a9 04 85 03 a9 11 85 10 a9 10 85 12 a9 0f 85 
0620: 14 a9 04 85 11 85 13 85 15 60 a5 fe 85 00 a5 fe 
0630: 29 03 18 69 02 85 01 60 20 4d 06 20 8d 06 20 c3 
0640: 06 20 19 07 20 20 07 20 2d 07 4c 38 06 a5 ff c9 
0650: 77 f0 0d c9 64 f0 14 c9 73 f0 1b c9 61 f0 22 60 
0660: a9 04 24 02 d0 26 a9 01 85 02 60 a9 08 24 02 d0 
0670: 1b a9 02 85 02 60 a9 01 24 02 d0 10 a9 04 85 02 
0680: 60 a9 02 24 02 d0 05 a9 08 85 02 60 60 20 94 06 
0690: 20 a8 06 60 a5 00 c5 10 d0 0d a5 01 c5 11 d0 07 
06a0: e6 03 e6 03 20 2a 06 60 a2 02 b5 10 c5 10 d0 06 
06b0: b5 11 c5 11 f0 09 e8 e8 e4 03 f0 06 4c aa 06 4c 
06c0: 35 07 60 a6 03 ca 8a b5 10 95 12 ca 10 f9 a5 02 
06d0: 4a b0 09 4a b0 19 4a b0 1f 4a b0 2f a5 10 38 e9 
06e0: 20 85 10 90 01 60 c6 11 a9 01 c5 11 f0 28 60 e6 
06f0: 10 a9 1f 24 10 f0 1f 60 a5 10 18 69 20 85 10 b0 
0700: 01 60 e6 11 a9 06 c5 11 f0 0c 60 c6 10 a5 10 29 
0710: 1f c9 1f f0 01 60 4c 35 07 a0 00 a5 fe 91 00 60 
0720: a6 03 a9 00 81 10 a2 00 a9 01 81 10 60 a2 00 ea 
0730: ea ca d0 fb 60

Into this code I can drop into my AVR based 6502 program Memory Loader...

Code: Select all

Code6502:
.dc.b 32,6,6,32,56,6,32,13,6,32,42,6,96,169,2,133
.dc.b 2,169,4,133,3,169,17,133,16,169,16,133,18,169,15,133
.dc.b 20,169,4,133,17,133,19,133,21,96,165,254,133,0,165,254
.dc.b 41,3,24,105,2,133,1,96,32,77,6,32,141,6,32,195
.dc.b 6,32,25,7,32,32,7,32,45,7,76,56,6,165,255,201
.dc.b 119,240,13,201,100,240,20,201,115,240,27,201,97,240,34,96
.dc.b 169,4,36,2,208,38,169,1,133,2,96,169,8,36,2,208
.dc.b 27,169,2,133,2,96,169,1,36,2,208,16,169,4,133,2
.dc.b 96,169,2,36,2,208,5,169,8,133,2,96,96,32,148,6
.dc.b 32,168,6,96,165,0,197,16,208,13,165,1,197,17,208,7
.dc.b 230,3,230,3,32,42,6,96,162,2,181,16,197,16,208,6
.dc.b 181,17,197,17,240,9,232,232,228,3,240,6,76,170,6,76
.dc.b 53,7,96,166,3,202,138,181,16,149,18,202,16,249,165,2
.dc.b 74,176,9,74,176,25,74,176,31,74,176,47,165,16,56,233
.dc.b 32,133,16,144,1,96,198,17,169,1,197,17,240,40,96,230
.dc.b 16,169,31,36,16,240,31,96,165,16,24,105,32,133,16,176
.dc.b 1,96,230,17,169,6,197,17,240,12,96,198,16,165,16,41
.dc.b 31,201,31,240,1,96,76,53,7,160,0,165,254,145,0,96
.dc.b 166,3,169,0,129,16,162,0,169,1,129,16,96,162,0,234
.dc.b 234,202,208,251,96

That is the Snake Game example from the same site.
Note the lack of HEX numbers... I am still resistant!

Ok, back to testing the 6502.
Once all functions have passed the IO test, I will do a wire clean-up and post photos and a video.

Cheers!
Radical Brad

[Oneironaut]

After some searching, and a recommendation from a buddy at Apatco.com, who makes and sells 6502 kits (shameless plug!), I think I finally found what I need here...

http://exifpro.com/utils.html

Has all of the features (and lack-of) that I wanted.
Highlighted code, compile, and save binary.

I will work with this for a while and see how it feels.



Radical Brad

[jmp(FFFA)]

You're not an emacs (https://www.gnu.org/software/emacs/) fan by any chance?

If you are, it will give you a single "IDE" from which you can do everything you want without ever leaving it. Syntax highlighting, compilation, generation of hex files, etc.

It's pretty minimalist compared to modern IDEs, which I gather is why it isn't so popular any more. However, it is infinitely more customizable than anything I've seen to date.

The EXIF 6502 Assembler, Simulator and Debugger (Mike Kowalski's) you reference does look nice. Only problem with it for me is that the help files don't work. BDD posted some additional English documentation I haven't yet looked at, but intend to when I have some time. Here's a link to his posting: viewtopic.php?f=4&t=3476&start=15#p40849.

[Oneironaut]

Thanks, will look at that on later as well.

So far EXIF is working perfectly, I have started my "Kernal" and hope to see the 6502 drawing some moving Sprites very soon.
The only thing I have not figured out yet (due to broken help) is which output format I will end up using.

I can export my code in the following formats...

- Intel Hex
- Motorolla S
- Binary Image
- Binary Program

I am steering towards Binary Program, is it is "probably" just a 64K image of the comiled program, which is perfect for loading into my AVR boot code for now.
I will have to peek around with HEXED soon to see how the binary files are made. If they were simply 64K images starting at 00000 and ending at 65535, then life will be good!

Radical Brad

[BigDumbDinosaur]

Oneironaut wrote:

So far EXIF is working perfectly, I have started my "Kernal" and hope to see the 6502 drawing some moving Sprites very soon.

There is a later version of the Kowalski simulator than you are using, which you can download right here. A couple of bugs that I discovered in the version you are using were fixed but Mike Kowalski never made the new version public (an oversight, most likely).

Quote:

The only thing I have not figured out yet (due to broken help) is which output format I will end up using.

I can export my code in the following formats...

- Intel Hex
- Motorolla S
- Binary Image
- Binary Program

I am steering towards Binary Program, is it is "probably" just a 64K image of the comiled program, which is perfect for loading into my AVR boot code for now.

I use the binary image output when I assemble (not compile ) code that will be burned into ROM. Be sure to use the Options button to set the address range to be saved before you generate the image. The default is to write the entire address space ($0000-$FFFF) to the output file. The output file will be raw binary with no header. Address space into which no code was assembled will be filled with $00.

If I am assembling code to be loaded into my POC unit I select the Motorola S-record format. S-record output consists of one or more S1 records and an S9 record. There is no S0 or S5 record. Only the address range in which your code has been assembled will be output to S1 records. That is, if the start of assembly is at $2000 and you generated $1000 bytes of object code, the first S1 record will load at $2000 and the last byte of the last S1 record will load at $1FFF.

The binary program output is broken. I've never used the Intel hex output, so I can't vouch for it.

[Oneironaut]

Hey Thanks Dino, good to have the latest version.

I have been exploring the file formats, and did find that the Binary Image is the one I will want.
In looking at the output in a HEX Editor along side the Memory Dump Window, it shows that both are identical.



I do want an entire 64K file, so this works perfectly.

Here is a very simple Visual Basic program I made to read the Binary Image and display it as GCC compatible bytes in a TextBox.
might be useful to someone for reference. Change the filename path and add a TextBox called dbug to a form.

Code: Select all

        Dim readbin As New IO.BinaryReader(IO.File.Open("D:\Shared\Plans\AVRCade\Logic 400x300 Vulcan-74\Tools\HEX2AVR\bin\Debug\Binary Code.65b", IO.FileMode.Open))
        Dim ln As String = ".dc.b "
        Dim tx As String = ""
        Dim x, y As Integer
        For y = 0 To 4095
            For x = 0 To 15
                Dim readbyte As Decimal = readbin.ReadByte
                If x < 15 Then
                    ln = ln + Str(readbyte) + ","
                Else
                    ln = ln + Str(readbyte)
                End If
            Next
            tx = tx + ln + " ; " + Str(x * y) + vbCrLf
            ln = ".dc.b "
        Next
        dbug.Text = tx

Thanks again everyone, the wealth of knowledge here is superb!

Radical Brad

[Oneironaut]

So far, I have been enjoying my dive into 6502 Assembly. It feels much like AVR Assembly, and at times, possibly a little more efficient (at least in number of lines of code).
Initially, I had fears of programming with only 3 available registers (AVR has 32), but when you realize what Zero Page does, you can really say that the 6502 has 3 special registers and 256 general working registers. This is a good design!

For comparison, here is the AVR code needed to Plot a single Pixel to the Vulcan-74 Graphics System...

Code: Select all

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// WRITE SINGLE PIXEL TO VIDEO MEMORY
////////// R25 = DESTINATION LOCATION X1.HI
////////// R24 = DESTINATION LOCATION X1.LO
////////// R23 = DESTINATION LOCATION Y1.HI
////////// R22 = DESTINATION LOCATION Y1.LO
////////// R20 = PIXEL COLOR (000-255)
////////////////////////////////////////////////////////////////////////////////////////////////////////
.global DrawVideo
DrawVideo:

// MUX 01 : LO ADR 005 : SPRITE DST X1 LO
ldi r18,5
out PORTB,r18

// SET ADDRESS.HI TO 512
ldi r18,2
out PORTC,r18

// SEND DATA TO DATABUS
out PORTA,r24

// TOGGLE 6502 CLOCK HL
sbi PORTD,1
cbi PORTD,1

// MUX 01 : LO ADR 006 : SPRITE DST X1 HI
ldi r18,6
out PORTB,r18

// SET ADDRESS.HI TO 512
ldi r18,2
out PORTC,r18

// SEND DATA TO DATABUS
ldi r18,0
sbrc r25,0
ldi r18,1
out PORTA,r18

// TOGGLE 6502 CLOCK HL
sbi PORTD,1
cbi PORTD,1

// MUX 01 : LO ADR 001 : SPRITE DST Y1 LO
ldi r18,1
out PORTB,r18

// SET ADDRESS.HI TO 512
ldi r18,2
out PORTC,r18

// SEND DATA TO DATABUS
out PORTA,r22

// TOGGLE 6502 CLOCK HL
sbi PORTD,1
cbi PORTD,1

// MUX 01 : LO ADR 002 : SPRITE DST Y1 HI
ldi r18,2
out PORTB,r18

// SET ADDRESS.HI TO 512
ldi r18,2
out PORTC,r18

// SEND DATA TO DATABUS
ldi r18,0
sbrc r23,0
ldi r18,1
out PORTA,r18

// TOGGLE 6502 CLOCK HL
sbi PORTD,1
cbi PORTD,1

; MUX 02 : LO ADR 017 : VIDEO MEM WE
ldi r18,17
out PORTB,r18

// SET ADDRESS.HI TO 512
ldi r18,2
out PORTC,r18

// SEND DATA TO DATABUS
out PORTA,r20

// TOGGLE 6502 CLOCK HL
sbi PORTD,1
cbi PORTD,1

// RETURN TO MAIN
ret

And now the same function, coded for the 6502...

Code: Select all

 ; ************************************************************
 ; *** PLOT SINGLE PIXEL TO VIDEO MEMORY
 ; *** ZP000 : DESTINATION LOCATION X1.LO
 ; *** ZP001 : DESTINATION LOCATION X1.HI
 ; *** ZP002 : DESTINATION LOCATION Y1.LO
 ; *** ZP003 : DESTINATION LOCATION Y1.HI
 ; *** ZP004 : PIXEL COLOR VALUE
 ; ************************************************************
VIDEO_PLOT:

 ; SET SPRITE DESTINATION LOCATION X1
 LDA 0	
 STA 517
 LDA 1	
 STA 518

 ; SET SPRITE DESTINATION LOCATION Y1
 LDA 2	
 STA 513
 LDA 3	
 STA 514

 ; SET SPRITE PIXEL COLOR VALUE
 LDA 4	
 STA 529

 ; RETURN TO CALLER
 RTS 

I will admit that the AVR code could be made smaller if it wasn't trying to simulate the 6502, and it was unrolled for speed, but the 6502 code is certainly smaller!
Zero page is great - I just reserve 16 bytes for calling subs, and this reduces a lot of overhead.
Later, I will count all cycles to consider code efficiency as well. The AVR is fast in that regard.

Ok, back to some wiring - I added the proper 10ns SRAM and included logic to disable the SRAM when reading registers on the Vulcan Board.
A full IO test will follow, and then some real 6502 coding can begin!

Cheers,
Radical Brad