6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 14, 2024 6:15 am

All times are UTC




Post new topic Reply to topic  [ 67 posts ]  Go to page 1, 2, 3, 4, 5  Next
Author Message
PostPosted: Sun Jul 07, 2013 1:51 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I am trying to figure out what to do next. I have a solid system with 64K RAM with Arlet's core on a 6502 Playground board and a serial link.

I wrote a few assembly tests. Now I would like to get at least a minimal monitor/bootloader going, hopefully without reinventing the wheel.

Any suggestions?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 5:15 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
enso wrote:
I am trying to figure out what to do next. I have a solid system with 64K RAM with Arlet's core on a 6502 Playground board and a serial link.

I wrote a few assembly tests. Now I would like to get at least a minimal monitor/bootloader going, hopefully without reinventing the wheel.

Any suggestions?

You could look at the source code for my POC unit, which has a ROM-resident monitor. It's written for the 65C816 but could be adapted to the 65C02 (a less complicated processor for which to write a monitor).

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 5:27 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
For 6502, Daryl has his SBCOS at http://sbc.rictor.org/sbcos.html with monitor, mini assembler, and EhBASIC if I understand it correctly, just taking a quick look at his site.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 6:12 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
Can you pre-load any of the RAM using your serial link? My XMODEM program is not too big and could be setup to run on reset and allow you to download a binary image. That would function similar to a bootloader. My SBC-2OS has that feature built into as well as the functions Garth mentioned.

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 6:39 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
8BIT wrote:
Can you pre-load any of the RAM using your serial link?

When the FPGA is configured with the 6502 core, any of the internal RAM is preloaded with data of your choice. So, bootstrapping is really easy.


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 2:36 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
Arlet wrote:
When the FPGA is configured with the 6502 core, any of the internal RAM is preloaded with data of your choice. So, bootstrapping is really easy.


Great!

Enso, if you are interested in my SBC-2OS, be aware that you can strip out any features you don't want to save space. Just let me know and I will help you with that. I can also help integrate your serial IO into it if you would like.

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 5:08 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
8BIT wrote:
...my SBC-2OS, be aware that you can strip out any features you don't want to save space. Just let me know and I will help you with that...


Sounds good, thanks! I started writing a monitor, but then decided that the world probably doesn't need another monitor only I would use. It would be nice to have a shared codebase for a minimal monitor easily adaptable to any small 65(c)02 system. Perhaps we can make it a permanent resource on 6502.org...

For starters, what assembler do you use? (keeping my fingers crossed that it's Linux compatible...)

I have several targets in mind for a minimal ROM system.

An XC3S700AN has 24 2K BRAMs which can be used as RAM or ROM, and there is a 64K RAM to fill in the gaps; that is tons of room. Decoding and muxing the BRAMs does take time and space, so I would love to keep it minimal anyway.

My secondary goal is for the monitor to be usable in a small XC3S50 system which only has 4 BRAMS (8K RAM/ROM total), a cheap board for control applications (6502uino?)

I would like some basic capability to receive a binary file, dump memory, enter hex bytes, and call/jump into code.

Arlet's core should be pretty easy to single-step. I haven't given it much thought yet...

EDIT: BDD, missed your post... Thank you, I will take a look. What assembler do you use?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 9:47 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
enso wrote:
For starters, what assembler do you use? (keeping my fingers crossed that it's Linux compatible...)


I usually use Tass (DOS based). I have also used the Assembler built into the Kowalski Simulator and the one included with CC65.

However, it would not be hard to port assembly code to another Assembler.

Which Assembler do you have in mind?

My Monitor would be quite small if you remove the assembler and disassembler. You could keep the xmodem routines to move data between host and target. That still would allow for memory Hex dump, modify, move, insert, and execute.

I will try to get that code set-up and let you know how much memory it takes.

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 9:55 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Daryl, thank you! Right now I am using Kingswood AS65, for better or worse, although I am not totally committed. I do have the toolchain set up - binary file generation and conversion to the FPGA BRAM.

I've been using GtkTerm on my Linux box as it is simple and has some debugging features I found helpful (like looking at the serial stream in hex). I am not sure it does xmodem, but it does allow you to send a binary file. I will have to look into that, as well as handshaking - it will probably be needed even at 35MHz.

I will take a look at your code as soon as I can.

Thanks again.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 10:32 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Got SbcOS.asm to assemble with Kingswood. Made everything lowercase and fixed some opcodes... Assembles to 4602 bytes... Now I have to figure out how to split the binary and stick it into 3 BRAMs...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2013 11:57 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
enso:

That utility program for which I posted the source, Bin2Hex.c, and you got running on your Linux development system is all that you need. The following few code fragments illustrate the way that Verilog will automatically initialize a Block RAM during synthesis.

The following code fragment shows the parameter declaration that sets the file name of the ASCII Hex memory initialization file.
Code:
    parameter pBootROM_File = "M65C02_Tst3.txt"

The following code fragment shows the declarations that determine the depth and width of the Block RAM. A parameter, pROM_AddrWidth (11), determines the size of the address variable and the depth of the ROM, Boot, itself. The width of the ROM and the output data signal are not parameterized, and are set to 8 bits. You can use a similar approach and set your ROM depth using a constant or as a parameter.
Code:
reg     WE_Boot;                    // Write Enable for the Boot/Monitor ROM
reg     [(pROM_AddrWidth-1):0] iAO; // Internal address pipeline register
reg     [7:0] Boot [((2**pROM_AddrWidth)-1):0];  // Boot ROM/RAM (2k x 8)
reg     [7:0] Boot_DO;              // Boot/Monitor ROM output data (absorbed)

The following code fragment demonstrates how to get the synthesizer to generate a block RAM. In this case, the synthesizer generated a single block RAM, but simply changing the parameter pROM_AddrWidth will let the synthesizer automatically aggregate as many block RAMs as needed to satisfy the specification. The initial statement's $readmemh function is a Verilog system function that is recognized by the synthesizer. It informs the synthesizer that the memory Boot should be initialized with the values represented in ASCII hexadecimal in the file pBootROM.
Code:
initial
  $readmemh(pBootROM_File, Boot, 0, ((2**pROM_AddrWidth)-1));
 
always @(posedge Clk)
begin
    if(WE_Boot)
        Boot[iAO] <= #1 DO;
       
    Boot_DO <= #1 Boot[iAO];
end

The following is a small snapshot of the memory initialization file. The first opcode, 0x4C, is an absolute jump to 0xF838.
Code:
4C
38
F8
3C
F8
40
F8
00

One reason to use this approach is that the other way to initialize memories using instantiation and initial statements within the instantiation is very tedious. The synthesizer essentially does that operation automatically using the technique demonstrated above.

Hope this helps.

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 08, 2013 2:14 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Michael, thanks, you are right. For the initial test I was instantiating the BRAM because I was mapping a part of it as RAM at page 0 through 6 and a vector page at $FF00... I was not sure how to do it in Verilog in a way that would make sense to the assembler...

For this project I can easily do what you are suggesting. My only reservation is that right now I am set up with Picoblaze tools to modify the final configuration file instead of rebuilding the entire project. My 6502 assembler-to-FPGA turnaround time is 1 second. I am not sure that will still be possible if I use verilog.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 08, 2013 3:21 am 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
Will have to look into the PicoBlaze environment.

Am currently working on boot loader for a PIC16C5x-compatible core that I am putting into the same FPGA I built for checking out my 65C02-compatible core. I expect to be able to program the Block RAMs with the boot loader from the SPI configuration EEPROM, but I don't think the cycle time for my approach will be as quick as you describe using your PicoBlaze approach.

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 08, 2013 6:06 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Michael, I am not near my dev machine and can't remember the details. The tool takes an ascii file (1 hex byte per line, no initial address line) and slams it right into the configuration bitstream file. Then the FPGA is reconfigured. The whole process takes about 1 second for my setup, including assembling. As you may suspect, I don't want to give up my turnaround time.

Interestingly, Xilinx is pushing away from that tool in favor of a JTAG loader. I don't like it.

The only drawback is that the BRAM location needs to be known and fixed.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 08, 2013 1:10 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
8BIT wrote:
I will try to get that code set-up and let you know how much memory it takes.


I have stripped down the SBC-2OS, removing the disassembler and mini-assembler. It has both the xmodem and Intel Hex downloaders but no uploaders.

It takes up about 3072 bytes, including the help text. If you remove the text, then it will take up only 2560 bytes. That included code to talk to a 6551.

Let me know if you are interested.

Daryl

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 67 posts ]  Go to page 1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: