I'm new here, and am contemplating building my own 6502 based single-board computer.

I've decided on some aspects of the design, and yet others are up in the air.

The thing I came here searching for and looking for was a small 'monitor' program or a small programming 'language' that I could stick in the device so I could actually DO some coding, something that's preferably open-source so I can modify it to my heart's content. I came here from looking up this topic:

viewtopic.php?f=2&t=3443

Which lead to this one:

viewtopic.php?f=2&t=2612&hilit=VTL

Now the thing is..


I HAVE NO CLUE WHERE TO START!

The code you guys provide... I'd have no clue where to edit it so.. it would use a different serial port IC, or even a different memory location for it.

Same thing goes for integrating the Programming language with the monitor.

I'm just needing a place to start.


The specs on the machine i'm planning on are rather.. vague, but here goes:

128k by 8 SRAM in the lowest 32k of ram (planning on using a bankswitching scheme so I can have 4 separate 32k blocks in use)
8k of EEPROM in the uppermost 8k of memory space... along with an 8-bit data latch tied to the 'writing' of the uppermost 8k of memory space. The lowest 2 bits of which are tied to the upper 2 address lines of the 128k by 8 SRAM previously mentioned.

I'm also wanting to keep the I/O memory space similar to that of the C64 (so I could POSSIBLY play SID tunes on this device)

Sorry for the long and 'rambling' post, but I'm kinda thinking stream-of-consciousness in regards to all that I'm unsure of/remembering I need answers to.

I wouldn't bother keeping the memory map like that just for the sake of playing SID sounds.

Writing a program to modify other programs so that they write to a SID in a different location would be the easy part about doing that.

It's always best to start at the beginning. What I mean by that is start with a small block and expand from there. What is your current level of comfort with 6502 assembly programming? Can you take some documented source code and make sense of it, or is that too big of a bite?

You could start out using a simulator, such as Kowalski's. It has simple IO built in and you could start by building the IO routines your will need. Things such as character output, string output, hex output or decimal output. Then you can add in input parsing. Before you know it, you'll have a simple monitor.

You could also put an existing monitor in the simulator and step through it until you understand how it works. I could easily provide a working copy of my SBCOS to use with Kowalski including source code that you can modify.

Others might be able to help with other Monitor's as well.

I'm not sure if this is the right direction for you - what do you think?

Kowalski Link:
http://www.exifpro.com/downloads/6502_1.2.12.zip (Link edited - thanks BDD!)

SBCOS link:
http://sbc.rictor.org/sbcos.html

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Use this link instead. The version on the page you linked has several bugs in it that were subsequently fixed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Really the I/O on my device is going to be flexible (e.g. I've not quite nailed down where it will be /exactly/ but it can work around other ideas I have.



I guess I could edit code a bit? I'm not /that/ familiar with some of the tricks and such with the cpus but I could figure things out if I read into it enough XD

I guess i'm just looking for something that I could edit to utilize the serial port I end up using on the board at the required memory location.

+1. The assembly-language code should have no addresses in it. You refer to registers by name, for example, the 6522 VIA has 16 register addresses, and you call them by PB (port B), PA (port A), DDRB (data direction register for port B) DDRA, SR (shift register), T1CL (timer 1 counter low byte), etc.. Before the code starts, you'll have equates (usually using the EQU assembler directive) telling what the address is of each named register. Then when you run the assembler on your source code, the names will get assigned the right number for the machine-language output. For example, if the VIA's PB is at address $6000, then every time the assembler sees "PB," it will replace it with $6000. If you change the address decoding so it gets moved to $8000, you just change the one line that says
to

and now the countless references to PB get changed in the machine-language output the next time you run the assembler. You don't have to change them all manually. Again, your assembly-language source code should have very few numbers in it, and maybe no actual addresses at all except in the EQUate lines.

A working monitor program will save you time getting going, but is not necessary. I got started without such a thing. This was 1985, when most households had no computer yet. Mine was no exception. I wrote, by hand, what was more or less what I later would find out was essentially a monitor program, assembled it by hand, and made a manually operated EPROM programmer to put my creation in EPROM. Yes, it was a very slow and error-prone process. A friend had made himself an EPROM programmer he could use with his Hewlett-Packard hand-held computer, and offered to help, so I took my hand-assembled machine-language program, maybe 600 or 800 bytes' worth, to his house, and dictated while he punched it in, then he read it back and edited where there was an error, then he programmed a ROM for me. It all worked on first try, but was not really useful. Learning what would be useful was a process.

I had no assembler to start. Today, it's easy to get one. You'll want to get a good one you can grow with (meaning it ought to have macro capability) and learn it. My links page has a section of assemblers at http://wilsonminesco.com/links.html#assem . Most of them are free. I have never used a simulator for 6502, and never really missed it. It seemed like the best place for one would be for understanding the I/O ICs, not so much the processor. I tried Microchip's MPSIM when I was first learning the PIC16 microcontrollers, and it was so cumbersome to use that I basically threw it out and went without. I've never been sorry.

Some of the relevant chapters of the 6502 primer are:

• Program-Writing: Where Do I Start?
• General Steps For A Successful Project
• Debugging
• Tips For Programming the 65(c)02 (sometimes affecting hardware design optimization)

Do go through the entire 6502 primer though. It is arranged logically, for new 6502 computer builders.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

My SBCOS uses just three IO access routines:



All you need to do is write the actual IO code for your USART and update the JMP locations.

I can help with the IO code and can set up the source to assemble. My monitor includes a disassembler and can also include an Apple II-like mini assembler, XMODEM data transfer, and EhBASIC. You can select the features you want and reduce size by not including everything.

I can also set it up in the Kowalski Simulator for you to play with if you like.

Please do use BigDumbDinosaur's link - I forgot about the bugs in the current version. Thanks BDD for pointing that out.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

So basically what you're saying is that if i didn't want part of the SBCOS, say EHBasic... i'd just not compile using those first 2 include lines?

And yes, any help setting it up would be.. helpful XD

Yes, for EhBASIC and/or XMODEM. If you wanted to remove the mini-assembler, you'd have to do some editing of the SBCOS.asm
content. Also, if space was ever a factor, you could also remove the Help text.

I will set up a couple of examples to work with the Kowalski Simulator. Give me a few days... my free time is limited.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Hi all,

Here is the first source file for use with the Kowalski Simulator.

You have to load it first.

There are some notes at the top of the file for setting the Simulator options. Please follow all of them.

Next, assemble it (F7), then enter the debugger (F6).
Then, click on the RST icon on the right end of the toolbar. The IO window should pop up with the Monitor welcome message.

Once that is working, you can play with the monitor to see what it can do. You can stop the debugger and single-step the simulator to see it stepping through the code (it should be in the input character loop).

Let me know if you make it this far.

thanks

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Okay, I got it up and running, but am I right in saying that the code is 12k in size? Or at least it starts assembling at 0xD000h? (I was planning on having my computer use an 8K CAT28C64 EEPROM chip for ROM memory.

I also notice if I type "D000 L", the result it gives me back is:



but if i type in "CFFF L" I get the 'proper' listing of:



which is the first line of code in your asm file.



I don't know if this is 'part' of the monitor's limitations or if its a bug.

But the main thing is the (seemingly) 12K romsize.

The syntax is D000L<enter>. The Space character is actually a command as well, which dumps the hex value at the current address. So D000 L was setting the address pointer to D000, dumping that location and incrementing the pointer, THEN doing the L command.

Also, you can type D000L<enter> and then just L<enter> to continue the disassembly. Typing LLLLLLLLL<enter> will disassemble 9 pages of code. D000-FFFFL<enter> will disassemble the range. You can press any key to cancel during the dump.

I just picked $D000 as an arbitrary place to start. The Monitor with mini-assembler and help text takes up just over 4k.

D000-D013 is the IO code
D014-E11E is the monitor itself.
FF00-FF1A is the reset code.
FFFA-FFFF is the vector table.

You can change the *= $D000 to *= $ED00 and it will work just fine.

If you comment out the *= $FF00 line at the start of the reset code, you can start to program $EE00.
Removing the Help Text will get it down to $0BBA in size (under 3k)
Removing the mini assembler & help text gets it down to $0870 (just over 2k).

I hope that helps.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I poked around a bit more after I made my post and realized that the code definitely wasn't 12k in size. From the code you sent to me, I found out the main part of the code ran from D000-E120h [which is just over 4k in size] The thing I'm a bit curious about right now.. is how is the terminal screen 'mapped' to what I see in the computer? Is there a section of ram that's being used as a 2000 byte (80x25 characters) screen buffer? or is the "Set IO memory area active starting at $C000" line meant to utilize a psuedo-serial device built-in to the emulator?

I do get the 'use your own routines' bit in regards to the I/O. If i wanted to use a specific I/O chip, I'd probably initialize it in the anti-zero-page (FF page) initialization routine before dropping into the monitor code. Also, if i wanted to use bank-switched RAM anywhere, and was using the data latched off of a memory write to the ROM memory, like a 'write' to FFFF would latch the data lines into an 8-bit latch. I would also insert that into the code at the anti-zero-page.

I'm glad you're trying to help me 'cram' the assembler and monitor into a small amount of memory.. but just over 4k of space.. is good enough for me at the moment. It gives me nearly 4k of ROM-space to add routines and such of my own design in the future! Well maybe 3.5k or so but eh, i'm not nit-picking. That's plenty of room to say.. add an I2C read/write routine or two.. to facilitate reading and writing.. and maybe in the future SAVING of memory/programs/data to small I2C EEPROMS.

Yes to this - "Set IO memory area active starting at $C000" line meant to utilize a psuedo-serial device built-in to the emulator?

There is no screen buffer in the Monitor code.

Glad to help!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Alright... I know I might sound/seem like a persnickety type.. but I'm up for a bit of a challenge. I did a quick side-by-side comparison of the two source codes.. and the mixed-case-ness is something i wish i could help out with. First off, what version of TASM would I need to get so i could check/vet out the case-ness of the original code, and secondly, I noticed that you removed bits of the from-the-website code that pointed towards 'basic'. Any chance that you could send me a copy of the 'full' code, that includes the basic interperter? I could easily figure out what bits were modded using the side-by-side editing text-comparison software, and also possibly fix the mixey case at the same time.