I whipped up a very, very small monitor program (less than a page) for the 65org16, from the idea I mentioned here:

viewtopic.php?p=14200#14200

It doesn't do much, but you can dump memory, write memory, and call routines (which, in theory, is all you need), so it might be useful for getting hardware up and running. (The idea being that the smaller it is, the less there is that can go wrong.) It's available here:

http://www.lowkey.comuf.com/

I remember when I was interested in your work on the one page assembler back when I was trying to make a 6502SoC...

Thanks for making a version for the 65Org16!
I would like to make sure your efforts do not go to waste, especially after my efforts to port a more complicated 6502 MLM to 65Org16 may fail.

I've seen your efforts on eFORTH just require a charin and a charout routine... If it's that simple, it should work with what I have so far.

That's great Bruce, thanks: it's fine on Mike's py65 with a few minor mods.

Here's an example of poking in a program and running it (CMON is pre-padded with 4k of zeros because I can only load at address zero):



Here's the build process:


These are the changes I made:

Oops, I see I've gotten mixed up with the one page assembler...

I can try your C'MON tomorrow on the 65Org16 DevBoard. Man I can't believe how compact the code is!

I've tried it out. I get the dash, and it echoes what I press on the keyboard to the screen, but nothing when I type in an address and an 'x' for the Hex Dump command or an address and a 'g' for Go command...

Both my INPUT and OUTPUT routines save the Y register.
My INPUT routine goes in a loop until a key is pressed and returns and ascii value in the Accumulator.
My OUTPUT routine sends an ascii value below $7F to the screen. It does look for $0D (carriage return) but not $0A (line feed).
I am using addresses $10 and $12 for the respective ADRESS and NUMBER variables used by C'MON.

I have a feeling some indirect STA is outside of my available memory...
Still looking at the code.

Does the .org for C'MON have to be $00001000?

I just now tried putting an image of CMON in RAM at the beginning of $00001000-$00001FFF, with no change in results...

Ok, how much RAM does this thing need?!

Does HXA translate $1000 into $00001000 or $10000000?

HXA deals in signed and unsigned 32-bit integers. So internally:



Four eight-bit octets. It's only at output time that individual octets ever get shifted around to whatever order HXA has been asked to provide.

If you're using this CPU definition and code:



then you get this:



If you'd prefer that quantities too large to fit into a byte cause an error rather than being silently truncated, use ".ubyte" (unsigned byte) or ".sbyte" (signed byte) instead.

So it echoes the X, but you don't get a screen dump? Hmm... I don't see any potential issues with anything you've stated.

I did find a bug (and have uploaded the corrected source code), but it only applies to characters >= $7F

A couple of thoughts: Does it give you a new prompt when you press Enter? What have you initialized the stack pointer to?

I'd recommend placing a JSR OUTHEX at various points to see how far the code gets. E.g. place one after BNE M7 then run it and type @ and see if it outputs anything. The SBC #$77 is where it tests for the G command. The CMP #$FFF1 is where it tests for the X command; you could try placing a JSR OUTHEX before the CMP #$FFF1 and see if the code gets that far and if so what (value of the accumulator) it outputs.



You can put it anywhere you like.



Not much. 2 bytes for ADRESS, 2 bytes for NUMBER, a dozen bytes for the stack (plus however much your I/O routines use).

I'd look at this one first! Whereas py65 does init the stack, 65Org16 does not(*), so we need
before the first JSR, and the $something needs to be correct according to the platform's memory map.


This is crucial too of course - let's see what you're seeing...

Cheers
Ed

(*)I think it could, but from simulation, I'm pretty sure it doesn't - all inherited behaviour.

Yes I get the prompt each time I hit enter.


I've run into something like this before, so I've included the following in the 65Org16.b core:



What about that STA (ADRESS),Y and JMP (NUMBER)? Where is this in memory?


I'll try this out.

It's working!
Problem was on my end: My OUTPUT routine was not saving the Accumulator before it was called.



C'MON will be great for testing SDRAM when the time comes. I'm putting a board together for Arlet and am about 1/2 way done completion. Also, I think I'll abandon my efforts to porting HESMON. C'MON does the primary functions of memory dump, and store values in consecutive memory locations very well.

Awesome to see a window of data into 4GB!!!

Great job Bruce! You saved me many days/months of work. I owe you one.

Although it may be moot at this point, to answer these questions, the only 2 bytes of RAM that JMP (NUMBER) uses are the 2 bytes used by NUMBER itself. The routine you jump to can be in ROM. Likewise, the only two bytes used by STA (ADRESS),Y are the 2 bytes used by ADRESS itself, though usually the address you store to is in RAM -- but it could be an I/O location.



You're right; OUTPUT does need to preserve the accumulator. That should have been in the documentation, so I've added it.



You may find youself wishing for more commands in the future, though. You could you extend C'mon little by little when you want additional features, or maybe it'd be easier to resume porting HESMON. But I'd suggest at least making enough notes so you can pick it up again at a later date if you choose, i.e. putting it on the back burner, rather than abandoning it.

I've made comments to HESMON, but I think I'm going to start modifying yours. I've already changed it to dump 256 locations instead of the original 128. I'd like it to perform a CR afterwards too, working on that (I know you made it to be as compact as possible, no negative critiques from me)...

I'd like to add an 'exit' command to C'mon, which should be easy, so it can be called from/return to another program. Also, I'd like to change the ASCII readout at the end of each line to have 2 characters per 16bit byte. Maybe in the future Load & Save commands, and a Fill memory command. I imagine Save would be very similar to the dump command 'x', except an end memory location would need to be spec'd, along with an output register to determine if the routine was outputting data to the screen/FLASH/etc.

I found another bug (the BNE at the end of the @ command should have been BCS). I have corrected that, added some comments, and reorganized the source code to make it easier to add commands. Same bat features, same bat size.