TNAN0@CCVAX.IASTATE.EDU (11/15/90)
Hello All, I asked this question once before (quite awhile back) and received no reply, so I feel it's time to ask again. I am enjoying programming my HP48SX in machine language, but I am running into problems accessing display memory. I need to know how video memory is laid out and where the elusive pointers are that keep track of its current location. I know that the most current version of CHIP (v 2.25 I believe) keeps tabs on it very well, but I have not seen the source for 2.25 available anywhere. Also, where is the most complete set of internal addresses available from? I have merged my SAD and TA comments into one huge listing, but still I see quite a few addresses posted here at comp.sys.handhelds that I have not come across in my own travels... And the last... Has anyone got SAD to run on a PC clone yet? It seems that SAD expects its compiler to use at least 4-byte integers, and most PC compilers use only 2-byte integers... I ran through and changed all "int"s to "long int"s except for ARGC... It compiles fine, but when I disassemble it only prints the first couple of columns... (Thus I can only see the disassembly if I have SUPPRESS COMMENTS on...) I can handle this one myself, but it also freaks out when it tries to disassemble anything with a "D" in the ML... I just can't figure out why... I'll have to get my hands pretty dirty to figure out what it needs, so I'm looking for a cheap way out... Any suggestions? So, a summary: 1) Where is video memory and how is it structured? 2) Where is a good list of internal addresses? 3) Is there a pre-compiled version of SAD available for the PC? Thanks for all of your support: ---Xeno (Gary Snethen) tnan0@isuvax (Bitnet) tnan0@ccvax.iastate.edu (Internet)
bson@rice-chex.ai.mit.edu (Jan Brittenson) (11/16/90)
In article <0481BF77937F618367@ISUVAX.BITNET> TNAN0@CCVAX.IASTATE.EDU writes: > I am enjoying programming my HP48SX in machine language, but I am > running into problems accessing display memory. I need to know how > video memory is laid out and where the elusive pointers are that keep > track of its current location. @70551: menu GROB; 131x8 @70556: stack GROB; 131x56 @7055b: current display GROB @70560: graph GROB; at least 131x64 @70565: graph GROB (?) I prefer using 70556 for TEXT, 70560 for PICT, and 7055b for the current display mode. (Notice that these are pointers to GROBs, not GROBs themselves.) > Also, where is the most complete set of internal addresses available from? HP/CV? :-) > It seems that SAD expects its compiler to use at least 4-byte > integers, and most PC compilers use only 2-byte integers... Can't all PC compilers be set to default to 32-bit ints? It's fairly resonable to assume that argc and other system-defined int's conform to the specified size. (Be happy I switched from GCC's 64-bit `long long' to the more portable 32-bit int!) What compiler are you using? The last time I looked at MS-DOS, MSC had a library that looked very much like it contained the basics of unix' libc. SAD uses qsort(), for instance. The fact that you got it to link at all, is a good indicator that someone has tried to be unix compatible. Suffice to say that SAD wasn't ever intended for use on PC/XTs. I very much doubt MS-DOS virtual address space (= 640k) will stand up to SAD's needs. Especially in 1.03 which automatically deduces format info and generates symbols. I doubt an MS-DOS machine will ever be able to disassemble the entire ROM (00000-6FFFF) without running into memory problems, since this would involve perhaps tens of thousands of user-defined symbols, 100000's of generated symbols, as well as comments and cross referencing tables. Notice that 1.03 also cross references auto-symbols, so you're in deep shit here. Partial disassembly will never yield the same results. I don't mean to bash MS-DOS here; just state the fact that it has a memory model everyone else stopped using in the early 80's. I don't have any good libraries around for work-file stuff anymore, and besides, it would make SAD prohibitively slow to put the symbol table or xref tables, even partially, and however well cached, in a file. Sorry about this. I sincerely hope SAD will still prove somewhat useful for MS-DOS users, though. > It compiles fine, but when I disassemble it only prints the first > couple of columns... (Thus I can only see the disassembly if I have > SUPPRESS COMMENTS on...) It's a little hard to tell exactly what's going on from your description - can you mail me a sample? > it also freaks out when it tries to disassemble anything with a "D" in > the ML... I just can't figure out why... Do you mean whenever the mnemonic contains the letter `D' or whenever the opcode contains (starts with?) the hex digit D? What happens - do you suspect that it scambles the memory? I just discovered the master bug in SAD 1.03, by the way. It is present in 1.02 also - there MUST be a format specified at address 0. This is present in `stdformats' as distributed with 1.02. I won't fix this bug, just keep this in mind - don't remove the 0:c from .formats! Perhaps this is somehow related to your problem - make sure SAD reads the formats file; you have to rename it for MS-DOS and edit sad.h to reflect this name change.