ANNOUNCE: C'mon, the Compact MONitor

dclxvi · Post by **dclxvi** » Sun Jan 22, 2012 9:35 pm

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/

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Jan 23, 2012 12:45 am

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.

BigEd · Post by **BigEd** » Mon Jan 23, 2012 12:08 pm

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

(Edit: Bruce's site is presently offline, so please see this archive.)

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):

Code: Select all

Reset with new MPU 65Org16
Wrote +4331 bytes from $00000000 to $000010ea
-1000x
00001000 004C 100B 0000 00A5 F005 0029 00FF 0060 LK@%E)?`
00001008 0085 F001 0060 00D8 0020 10E2 0000 00A9 EA`X b@)
00001010 002D 0020 1008 0000 00A9 0000 0085 0003 - H@)@EC
[snip]
-3000 @ 00a9,000a,0020,1008,0000,00a9,0045,0020,1008,0000,00a9,000a,004c,1008,0000,
-3000 x
00003000 00A9 000A 0020 1008 0000 00A9 0045 0020 )J H@)E 
00003008 1008 0000 00A9 000A 004C 1008 0000 0000 H@)JLH@@
00003010 0000 0000 0000 0000 0000 0000 0000 0000 @@@@@@@@
[snip]
-3000g
E

-

Here's the build process:

Code: Select all

./HXA_TW.EXE CMONO16.ASM
xxd CMONO16.OBJ | xxd -r -s 8192 > CMONO16.bin
PYTHONPATH=py65/src python py65/src/py65/monitor.py -m 65Org16 -l CMONO16.bin -g 1000

These are the changes I made:

Code: Select all

*** CMONO16.ASM.bruce   2012-01-23 09:41:06.000000000 +0000
--- CMONO16.ASM 2012-01-23 11:36:55.000000000 +0000
***************
*** 13,20 ****
  
         .org $1000
  
! INPUT  .equ $7F86
! OUTPUT .equ $7F83
  
  ADRESS .equ 0
  NUMBER .equ 2
--- 13,29 ----
  
         .org $1000
  
!        JMP MON
! 
! INPUT  LDA $F005 ; py65
!        AND #$FF
!        RTS
! 
! OUTPUT STA $F001 ; py65
!        RTS
! 
! ;INPUT  .equ $7F86
! ;OUTPUT .equ $7F83
  
  ADRESS .equ 0
  NUMBER .equ 2
***************
*** 37,42 ****
--- 46,53 ----
  M5     JSR INPUT
         CMP #$0D
         BEQ M1
+        CMP #$0A ;; for linux
+        BEQ M1
         CMP #$20
         BCC M5
         CMP #$7F

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Jan 23, 2012 1:23 pm

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!

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Jan 24, 2012 2:08 pm

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?

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Jan 24, 2012 3:41 pm

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

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Jan 24, 2012 4:06 pm

Ok, how much RAM does this thing need?!

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

teamtempest · Post by **teamtempest** » Wed Jan 25, 2012 12:14 am

Quote:

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

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

Code: Select all

$1000 = $00001000

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:

Code: Select all

.cpu T_32_M16 
assume BIT32=1032, BIT32R=3210

.org $C000

.byte $1000
.word $1000
.byte $89ABCDEF
.word $89ABCDEF

then you get this:

Code: Select all

0000C000: 10 00
0000C001: 10 00 00 00
0000C003: CD EF
0000C004: CD EF 89 AB

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.

dclxvi · Post by **dclxvi** » Wed Jan 25, 2012 3:20 am

ElEctric_EyE wrote:

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...

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.

ElEctric_EyE wrote:

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

You can put it anywhere you like.

ElEctric_EyE wrote:

Ok, how much RAM does this thing need?!

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

BigEd · Post by **BigEd** » Wed Jan 25, 2012 4:02 am

dclxvi wrote:

What have you initialized the stack pointer to?

I'd look at this one first! Whereas py65 does init the stack, 65Org16 does not(*), so we need

Code: Select all

  LDX #$something
  TXS

before the first JSR, and the $something needs to be correct according to the platform's memory map.

Quote:

Does it give you a new prompt when you press Enter?

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.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Jan 25, 2012 9:08 am

dclxvi wrote:

... Does it give you a new prompt when you press Enter?...

Yes I get the prompt each time I hit enter.

BigEd wrote:

I'd look at this one first! Whereas py65 does init the stack, 65Org16 does not(*), so we need

Code: Select all

  LDX #$something
  TXS

before the first JSR, and the $something needs to be correct according to the platform's memory map...

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

Code: Select all

initial
	begin
	AXYS[SEL_A] = 0; //init accumulator
	AXYS[SEL_X] = 0; //init x register
	AXYS[SEL_Y] = 0; //init y register
	AXYS[SEL_S] = 16'hffff; //init stack
end

dclxvi wrote:

ElEctric_EyE wrote:

Ok, how much RAM does this thing need?!

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

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

dclxvi wrote:

...I'd recommend placing a JSR OUTHEX at various points to see how far the code gets...

I'll try this out.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Jan 25, 2012 4:26 pm

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.

dclxvi · Post by **dclxvi** » Thu Jan 26, 2012 2:46 am

ElEctric_EyE wrote:

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

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.

ElEctric_EyE wrote:

My OUTPUT routine was not saving the Accumulator before it was called.

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

ElEctric_EyE wrote:

Also, I think I'll abandon my efforts to porting HESMON.

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.

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Jan 26, 2012 5:17 pm

dclxvi wrote:

...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.

dclxvi · Post by **dclxvi** » Sat Jan 28, 2012 9:35 pm

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.