EEVblog Electronics Community Forum

Products => Computers => Programming => Topic started by: eti on August 29, 2020, 10:31:22 pm

Title: A little stuck generating bytes for a 6502 test experiment
Post by: eti on August 29, 2020, 10:31:22 pm
As usual in software and the world of computing, one is often FORCED to become distracted from the task in hand, only to have to go down a rabbit hole of convoluted learning, just to accomplish ONE simple goal:

I am learning 6502 assembley, I know a TINY bit of Python, and the Python example code I give here is from a 6502 tutorial:

Code: [Select]
rom = bytearray([0xea] * 32768)


rom[0x0010] = 0xad
rom[0x0011] = 0xff



with open("rom.bin", "wb") as out_file:
 out_file.write(rom)

Okay, so this generates a 32k bin file, populated with "ea" from beginning to end EXCEPT for the 0x0010 and 0x0011 locations.

Question: without vanishing down a distracting rabbit hole of needing to trawl the web, piecing together fragments of poorly-written "tutotials", most of which make VAST assumptions as to the knowledge level of the reader... how do I specify *A RANGE* of addresses - let's say "0x20 to 0x30" to fill with a certain byte? Example - I want to fill 0x20-0x30 inclusive, with "ff" data?

Many thanks!
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: Ian.M on August 29, 2020, 11:10:17 pm
What do you want to do? Learn Python, or learn 6502 assembly language?

Just about every macro assembler I've ever used has some sort of 'fill memory range' directive.  They almost invariably also have a means of repeating an instruction or block of instructions.  Therefore why aren't you writing assembler source to generate your desired ROM image?
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: eti on August 29, 2020, 11:17:40 pm
What do you want to do? Learn Python, or learn 6502 assembly language?

Just about every macro assembler I've ever used has some sort of 'fill memory range' directive.  They almost invariably also have a means of repeating an instruction or block of instructions.  Therefore why aren't you writing assembler source to generate your desired ROM image?

You have a valid point. However, for now, I am taking baby steps to learn, and simply want to know how to achieve what I outlined in my OP, using a simple modification of the python supplied (if possible). You are right, and now you see my conundrum - I simply want to fill a .bin file with specified data - however, I do not feel a 6502 can do this as quickly as I need (this is a means to an end, the python, merely a quick tool to do this job)

Thanks
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: Ian.M on August 30, 2020, 12:44:04 am
So you are going down the deep dark Python distraction road!
See https://www.pitt.edu/~naraehan/python3/more_on_for_loops.html (https://www.pitt.edu/~naraehan/python3/more_on_for_loops.html)

You'd want a for loop with a numeric range.  Something like:
Code: [Select]
for addr in range(0x20,0x30+1):
   rom[addr] = 0xFF

Any 6502 tutorial that digresses into Python is most likely not really worth reading.
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: eti on August 30, 2020, 01:21:31 am
So you are going down the deep dark Python distraction road!
See https://www.pitt.edu/~naraehan/python3/more_on_for_loops.html (https://www.pitt.edu/~naraehan/python3/more_on_for_loops.html)

You'd want a for loop with a numeric range.  Something like:
Code: [Select]
for addr in range(0x20,0x30+1):
   rom[addr] = 0xFF

Any 6502 tutorial that digresses into Python is most likely not really worth reading.

Yeah you're right, but I just needed a quick tool to generate the .bin, and your code works - thanks! I won't mention the video series, but in the series I am following, half of one of the tutorials goes off at a tangent showing us how to write some Arduino code to make a 6502 pin monitor; I was of the same opinion as you, re distractions, when I first watched it, but I see he's showing us how to monitor... I was just like "Ermm, I thought this was 6502 ASM, 'how to make a bus monitor in Arduino IDE' " but since his content is SO SO well explained and of excellent quality, I can overlook it, and who am I "set him straight" - I am a n00b to all this 6502-ness! :)

Thanks so much - I was getting hung up, as I hadn't realised that hex numbers could be used in "range".
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: Jay_Diddy_B on August 30, 2020, 01:54:58 am
Hi,

It has been along time since I did 6502 assembly language. I first learned on the Acorn Atom and later on the BBC B computer.

From what I can remember

The opcode 0xEA is the NOP instruction. This means the processor does nothing and advances the program counter.

If you execute a ROM full of 0xEA you can use this to test the hardware addressing.

The 6502 will start by looking at address    0xFFFC/0xFFFD  (Reset vector)

This location should point point at the location where the program starts. The low byte in 0xFFFC and the High byte in 0xFFFD.

If you fill a 32k EPROM with 0xEA except

0xFFFC = 0x00
0xFFFD = 0x80

You may need some code like this, I am not 100% sure about this.

0xFF00 = 0x4C
0xFF01 = 0x00
0xFF02 = 0x80

This JMP 0x8000

this means when the 6502 executes the jump instruction at 0xFF00 it will jump to 0x8000 and keep executing the NOPs.


When the 6502 comes out of reset it will jump to 0x8000 and execute the NOPs incrementing the program counter.

This assumes the 32K EPROM is mapped into the memory map 0x8000 to 0xFFFF

Do you have the memory map for your development board?

Regards,
Jay_Diddy_B
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: eti on August 30, 2020, 03:00:56 am
Hi,

It has been along time since I did 6502 assembly language. I first learned on the Acorn Atom and later on the BBC B computer.

From what I can remember

The opcode 0xEA is the NOP instruction. This means the processor does nothing and advances the program counter.

If you execute a ROM full of 0xEA you can use this to test the hardware addressing.

The 6502 will start by looking at address    0xFFFC/0xFFFD  (Reset vector)

This location should point point at the location where the program starts. The low byte in 0xFFFC and the High byte in 0xFFFD.

If you fill a 32k EPROM with 0xEA except

0xFFFC = 0x00
0xFFFD = 0x80

You may need some code like this, I am not 100% sure about this.

0xFF00 = 0x4C
0xFF01 = 0x00
0xFF02 = 0x80

This JMP 0x8000

this means when the 6502 executes the jump instruction at 0xFF00 it will jump to 0x8000 and keep executing the NOPs.


When the 6502 comes out of reset it will jump to 0x8000 and execute the NOPs incrementing the program counter.

This assumes the 32K EPROM is mapped into the memory map 0x8000 to 0xFFFF

Do you have the memory map for your development board?

Regards,
Jay_Diddy_B
Thanks! :))

I have no dev board, I can't afford it.
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: ledtester on August 30, 2020, 04:37:05 am
Normally you would create 6502 assembly code using an assembler which takes text input and produces a binary object file -- much like a C compiler (or Java compiler).

Every assembler uses the same basic syntax, but there can be a lot of variation especially in the way constant data is specified.

If you go to the online assembler at https://6502asm.com you can see what assembly language looks like by bringing up any of the example programs.

This particular assembler uses the "dcb" directive to declare constant data areas. For instance, if you bring up the "alive.asm" example at the end you will see:

Code: [Select]
ypos:
 dcb $00,$02,$20,$02,$40,$02,$60,$02
 dcb $80,$02,$a0,$02,$c0,$02,$e0,$02
 dcb $00,$03,$20,$03,$40,$03,$60,$03
 dcb $80,$03,$a0,$03,$c0,$03,$e0,$03
 dcb $00,$04,$20,$04,$40,$04,$60,$04
 dcb $80,$04,$a0,$04,$c0,$04,$e0,$04
 dcb $00,$05,$20,$05,$40,$05,$60,$05
 dcb $80,$05,$a0,$05,$c0,$05,$e0,$05

which is declaring a data block of 64 bytes. Each byte is specified in the case. To specify that a range of bytes should be filled with a single constant value a different directive would most likely be used -- if such a feature is supported at all by the assembler. Otherwise you could always fall back on using a directive like "dcb" and just repeat the byte value once for each memory location.
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: Ian.M on August 30, 2020, 05:13:02 am
Ahhh...... I think I see where you are coming from.  I suspect you are workinfg through Ben Eater's Breadboard 6502 tutorials at https://eater.net/6502 (https://eater.net/6502)
He says up front (part #2 08:34) he's using Python because its quick and easy for him due to his personal familiarity with it.  Rather than *YOU* getting bogged down in learning Python, why not use whatever programming language you are most familiar with that runs on a PC and can easily output a binary file?  Alternatively consider using a HEX editor e.g. Frhed, and entering the opcodes directly.

http://frhed.sourceforge.net/en/ (http://frhed.sourceforge.net/en/)

I'll underline Frhed menu selections and bold data to be entered for clarity.  Start off with an empty new file and do Edit Append 32768 (or whatever your EEPROM size actually is in bytes if its smaller) to extend the file to the correct size.  Then  Edit Select all followed by Edit Fill selection with ... ea to fill the file with NOPs.  Then go to the end, and click on the 'e' of the byte thre bytes before the last one.  Type 0080 and the last few bytes of the file should now read 'ea ... ea ea 00 80 ea ea'.  Congratulations, you've just patched the reset vector to 0x8000, the start of your ROM.    You'll probably want to save the empty rom now so you can go back to it easily.  Now go back to the top of the file and you can type opcodes in directly without faffing around with Python!   

Odds are that whatever (E)EPROM programmer youi are using has similar hex editing capabilities, so you may prefer to learn how to fill memory and edit bytes in that.

Don't get too comfortable entering hex opcodes though as the next lesson introduces assembly language, which once you've learned the basics and how to drive the particular assembler, is a massive gain in productivity and ease of use.
Title: Re: A little stuck generating bytes for a 6502 test experiment
Post by: eti on August 30, 2020, 05:36:44 pm
Thank you so very much for all your time in offering such helpful advice, my friends! :)