6502.org • View topic - Software for the 65Org16.x (formerly 6502 SoC Project)

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

Software for the 65Org16.x (formerly 6502 SoC Project)

Page 7 of 8

[ 114 posts ]

Go to page Previous 1 ... 4, 5, 6, 7, 8 Next

Print view

Previous topic | Next topic

Author

Message

teamtempest

Post subject:

Posted: Fri Dec 30, 2011 1:59 am

Joined: Sun Nov 08, 2009 1:56 am
Posts: 390
Location: Minnesota

Quote:

Also what about ASR - arithmetic shift right? This would not shift in zero from the left, but the sign (logical shift left LSL = ASL, both shift in zeros from right).
http://en.wikipedia.org/wiki/Bitwise_operation
This could probably be more easily emulated with LSR and setting the sign with an OR.

Or not, if the MSB is clear. I saw this trick once, don't know if it's posted somewhere here already:

Code:

cmp #$80
ror

which preserves the sign bit while shifting right.

Top

fachat

Post subject:

Posted: Fri Dec 30, 2011 10:30 am

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1019
Location: near Heidelberg, Germany

Yes that is probably the reason why there is no ASR - you could easily emulate it.

However, that trick does not work with multi-bit shifts (aka m68k "quick" opcodes), or at least not easily.

In my 65k you could do (assuming DROR = direct - i.e. not via carry - rotate right, 3 is the number of shifts):

Code:

    CMP #$80
    BCC @1
    ORA #%00000111
    .BYT $2C
@1 AND #%11111000
    DROR3

So it would definitely be easier to do

Code:

ASR3

André

Edit: the original code was wrong, was missing the AND, to clear the sign bits...

Top

OwenS

Post subject:

Posted: Sat Dec 31, 2011 10:30 pm

Joined: Thu Jul 26, 2007 4:46 pm
Posts: 105

Most designs I've seen have a multiplexer on the carry input to the ALU allowing selection between

To me it seems reasonable to add something along the lines of "L[31]" to that, or the most significant bit on the "left input bus". Its a useful bit to have access to anyway.

Top

ElEctric_EyE

Post subject:

Posted: Tue Jan 03, 2012 8:43 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

So, weeks ago I had run the original HESMON binary through MKs assembler. Then I copied the text over to As65 and successfully made .bin & .coe files. I must make a memory map tonight.
Tomorrow, I'll adjust all my code to sit above HESMON which will be at $FFFFC000-$FFFFCFFF. I also have to adjust the "zero page" addresses I am using for all of my routines that read keyboard values and display characters on the TFT.

I'm trying to get a mental grasp on what exactly will happen when I run this original HESMON monitor made for the 6510/6502 adapted to the 65Org16. I'm pretty sure I'll get the startup screen to work. I'm sure I'll have to start modifying the display memory command so it works with 32 bit address first. Will this be trivial or next to impossible looking at someone else's code?

Top

teamtempest

Post subject:

Posted: Wed Jan 04, 2012 2:37 am

Joined: Sun Nov 08, 2009 1:56 am
Posts: 390
Location: Minnesota

Quote:

I'm trying to get a mental grasp on what exactly will happen when I run this original HESMON monitor made for the 6510/6502 adapted to the 65Org16. I'm pretty sure I'll get the startup screen to work. I'm sure I'll have to start modifying the display memory command so it works with 32 bit address first. Will this be trivial or next to impossible looking at someone else's code?

Well, this may be obvious, but MLMs deal quite a lot with memory addresses, as they are parameters for nearly every command offered. So there's probably a single subroutine somewhere that collects one. I'd say one of the first things you may need do is find that and modify it to collect 32-bit addresses instead of 16-bit addresses.

If you're only going to accept hexadecimal values, it's probably fairly easy. It might be as simple as adjusting a loop index to collect eight characters instead of four. But, hmm, because bytes are 16 bits wide, you may not need to change anything about where the collected value is stored, or what that storage location is used for afterwards.

If HESmon accepts other bases for addresses (offhand I don't recall), there's probably a separate routine for each one. Binary and octal are about as easy as hexadecimal. Decimal is just a bit more complex as you'll have to use a software multiply instead of a hardware shift as each character is collected.

Just some off-the-top-of-my-head comments.

Top

ElEctric_EyE

Post subject:

Posted: Wed Jan 04, 2012 6:54 am

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Nice pointer, thanks TT! This gives me a glimmer of hope, I think...

For HESMON to display memory the command is 'd', ascii #$44. I did a quick search throughout the code for this value and couldn't find any.
There are values $44 within a couple lookup tables in the code. That doesn't make any sense because I can easily see where it compares for '0D' ascii return, $46' ascii F for the fill memory command, and some other values for some other functions.

EDIT: I do see the ascii values for all of the commands in a lookup table. Strange how it apparently uses the lookup table for all commands. In the main loop it compares the value in location $39 (CharIn stores there) for just some of the commands. Still observing...

Top

ElEctric_EyE

Post subject:

Posted: Wed Jan 04, 2012 8:59 am

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

I think I found the heart of HESMON.
29 Indirect JMP locations for command functions based on a table @FFFFC83F right after the ascii table used for the single letter commands.

Code:

             LDX #$1C
eC28D:
             CMP eC822,X            ;ASCII TABLE FOR COMMANDS
             BNE eC2A5
             STA $39
             TXA
             ASL A
             TAX
             LDA eC83F,X
             STA $C1
             INX
             LDA eC83F,X
             STA $C2
             JMP ($00C1)        
eC2A5:
             DEX
             BPL eC28D
             JMP eC5C0

Micromon's "heart" is very similar, posted below. SuperMON's code has nothing similar...

Code:

eC157:
   LDX #$1F
eC159:
   CMP $CF79,X
   BNE eC171
   STA $0349
   TXA
   ASL
   TAX
   LDA $CF99,X
   STA $C1
   LDA $CF9A,X
   STA $C2
   JMP ($00C1)
eC171:
   DEX
   BPL eC159
   JMP ($0360)

EDIT (1/12/2012): Added comparisons

Last edited by ElEctric_EyE on Thu Jan 12, 2012 9:30 pm, edited 1 time in total.

Top

ElEctric_EyE

Post subject:

Posted: Wed Jan 04, 2012 6:39 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Fixed the Jump table, now looking at Memory dump routine. That should be easier to get working than disassemble. I don't think I'll have time to convert all the routines, but I'll leave them all intact except for the hex to decimal conversion and test color ram. Almost time to test some modifications!

Code:

eC83F       .BYTE $C009,$FFFF                                   ;A - ASSEMBLE
            .BYTE $CFAE,$FFFF                                   ;B - BREAKPOINT SET
            .BYTE $C9FB,$FFFF                                   ;C - COMPARE MEMORY
            .BYTE $C5C6,$FFFF                                   ;D - DISASSEMBLE
            .BYTE $C88C,$FFFF                                   ;E - EXTERNAL RELINKER
            .BYTE $CA6D,$FFFF                                   ;F - FILL MEMORY
            .BYTE $CF48,$FFFF                                   ;G - GO (EXECUTE PROGRAM)
            .BYTE $CA98,$FFFF                                   ;H - HUNT FOR SEQUENCE
            .BYTE $C3B7,$FFFF                                   ;I - INTERPRET MEMORY
            .BYTE $C475,$FFFF                                   ;L - LOAD
            .BYTE $C3AC,$FFFF                                   ;M - MEMORY DISPLAY
            .BYTE $C88F,$FFFF                                   ;N - NEW LOCATOR
            .BYTE $CB8C,$FFFF                                   ;O - OUTPUT DIVERT
            .BYTE $CBF4,$FFFF                                   ;P - PRINT SCREEN
            .BYTE $CF39,$FFFF                                   ;Q - QUICK TRACE
            .BYTE $C354,$FFFF                                   ;R - REGISTER DISPLAY
            .BYTE $C475,$FFFF                                   ;S - SAVE
            .BYTE $C9FE,$FFFF                                   ;T - TRANSFER MEMORY
            .BYTE $CCFF,$FFFF                                   ;U - TEST COLOR RAM
            .BYTE $CC47,$FFFF                                   ;V - VERIFY RAM FUNCTION
            .BYTE $CF4B,$FFFF                                   ;W - WALK PROGRAM
            .BYTE $CF16,$FFFF                                   ;X - EXIT TO BASIC
            .BYTE $C41A,$FFFF                                   ;: - MEMORY MODIFY
            .BYTE $C400,$FFFF                                   ;; - REGISTER MODIFY
            .BYTE $C41D,$FFFF                                   ;, - <USED IN ASSEMBLY ENTRY>
            .BYTE $CAF5,$FFFF                                   ;+ - HEX ADDITION
            .BYTE $CB17,$FFFF                                   ;- - HEX SUBTRACTION
            .BYTE $CB2A,$FFFF                                   ;# - CONVERT DECIMAL TO HEX
            .BYTE $CB3F,$FFFF                                   ;$ - CONVERT HEX TO DECIMAL

EDIT (1/5/12):List was previously inverted

Top

ElEctric_EyE

Post subject:

Posted: Sat Jan 14, 2012 12:29 am

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Ok, I must admit I had gotten diverted abit when I realized that there really would be no need for a 3x5 pixel character set on a 5.7" 800x480 TFT display. While I can barely read the characters on a most respectable 200 columns, I must get uncomfortably close to the display. This was not so on the 640x480 TFT.

I've decided to stick with the original C-64 for 8x8 pixel characters, and also add in a 16x16 character set. For the 8x8 characters, the 65Org16 has to shift out the upper 8 bits, wasting time. Which is OK, I guess, when 100 columns and 60 rows are needed. I got abit distracted trying to copy a certain font over from Windows that might fit into a 16x16 character matrix, which would be alot closer to the C-64 40x25 screen matrix @50x30.

I found an excellent program that I can use to create a 16bit hex data .txt file, from the graphic pixel input GUI. I'll have to do this manually which takes alot of time, so I had spent alot of time looking for a simpler solution. Turns out that simple solution costs alot of money, so I'll probably wind up inputting the 16x16 font pixel by pixel, and making small adjustments along the way for lowercase/uppercase pixel placements.

So, anyway I am back on track merging the HESMON with my "OS". The OS just being a collection of I/O drivers at this point executing in an orderly fashion.

Top

8BIT

Post subject:

Posted: Sat Jan 14, 2012 2:25 am

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1696
Location: Sacramento, CA

I have copy of the C-64 font set up in text data formatted as 8x8. It would not be hard to convert that to 16x16 (double each pixel in both directions).

When I made my font tables for the text video display and SBC-3, I used QuickBasic. With that you can print the entire font to a graphic mode screen and then capture the screen into an array. It was easy to then extract the pixel info into a text file.

Check this link for a sample: http://sbc.rictor.org/io/vid3.html

I can also email you both text files if you want to use them.

Daryl

Top

ElEctric_EyE

Post subject:

Posted: Sat Jan 14, 2012 1:54 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Hi Daryl,
The software I made has 3 bits in an attribute "16bit byte" that determines x1 thru x7 sizes (H&V same) and a font bit that currently chooses between 3x5 and 8x8. I'm thinking that in my application I really don't need such large characters as x7, and to sacrifice 1 size bit to add to the font bit. That would allow for 4 sizes and 4 fonts. Anyway, I wanted a higher detailed 16x16 font, not blocky because an 8x8 character is maybe 2mm big on the 5.7" TFT.
And I was thinking I could use your DOS font and put it right beside the C-64 font. Depending on which of the 8x8 fonts is chosen, the software could then do 8 LSRs or ASLs depending. This could save memory I am now wasting, as the unused 8bits are currently zeros.

Is the DOS font 8x8?

Top

8BIT

Post subject:

Posted: Sat Jan 14, 2012 4:50 pm

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1696
Location: Sacramento, CA

Both fonts are 8x8. I can take another look at the DOS fonts in QB to see if there is a native 16x16.

ADDED: I have access to an 8x16 DOS font if you would like that.

Daryl

Top

ElEctric_EyE

Post subject:

Posted: Sat Jan 14, 2012 5:15 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

8x8 DOS character pixel data in text file would be great! Thanks for your help.
I'll PM info...

Top

ElEctric_EyE

Post subject:

Posted: Tue Jan 17, 2012 5:43 pm

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA

Been under the weather last 2 weeks... But I've made some progress.

Recently, I've been looking up info on pseudo-random number generators, one which I could put inside the FPGA and simulate changing variables to test certain portions of my 65Org16 software. We've talked about the subject for true RNG's here, but this would have required external circuitry as far as I'm aware. Although, I have read somewhere on Xilinx forums that FPGA inputs could be setup for Schmitt-trigger type...

So this morning I've added a PRBS (Pseudo Random Bit Sequencer) to the project, that has a 16-bit output, I found here. It does truly look random as in the pic below I am "clearing" the screen with the data read from the PRBS and then I sent the text file (HxD license file) over the br@y terminal @256Kbaud. Sorry about the pic compression, photobucket does this auto. It truly does not do the TFT justice! Those are 8x8 characters on a 5.7" 800x480 TFT.

As you can see, the colors look pretty random (the display is only seeing the lower 8bits of the databus). One interesting observation: The PRBS active high reset is tied low, so one would figure it is always spitting random #'s after power-up. But when I repeatedly reset the CPU, and the CLRSCR routine clears the screen with the random numbers, the randomness is always the same. I would have expected this if I had tied the PRBS reset to the cpu reset...

For the rest of today, I am adding the 8x8 DOS font that Daryl very kindly shared so it sits next to the C-64 font pixel data for a better usage of BlockRAM. I'm not going to waste my time at this point inputting a 16x16 charset pixel by pixel. But the font bit selector is there, and so is the preserved BlockRAM.

Maybe tomorrow I will attack the I2C core again as it is fairly straightforward, to try to program the DS1085s.

When I feel up to par again, I will be back at integrating HESMON...

Top

fachat

Post subject:

Posted: Tue Jan 17, 2012 8:30 pm

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1019
Location: near Heidelberg, Germany

Hm, I am not so sure about that randomness. I don't know if it's compression artifacts either, but I think there are some regularities in the pseudo-random noise picture. It is somewhat apparent below the "you are selling" text in the last long line, where it looks like some regularly spaced vertical and horizontal lines shine through the noise.

You cannot say from such an observation if the pseudo-random noise is "noisy enough" unless you a) specify your concrete requirements and b) do a proper statistical analysis.

André

Top

Page 7 of 8

[ 114 posts ]

Go to page Previous 1 ... 4, 5, 6, 7, 8 Next

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

Who is online

Users browsing this forum: No registered users and 9 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