Jump to content

rje

Members
  • Posts

    1281
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by rje

  1. I'd like something exotic.
  2. I appreciate you geeking out on this... My brain is too tired to follow it, but I like to see this. And hope to try things out with it.
  3. That's a clever use of the assembler to write target-agnostic Sw*t16.
  4. ^ As we say in the software world, "code wins arguments". We can spend days arguing over algorithms, but there's no disputing a working solution.
  5. A library module would be nice, since my custom trig things are neither particularly usable nor documented, so... Looking over the stuff prog8 has, plus my using C for the past year for the X16, has finally started to pique my interest.
  6. Besides... watching David's channel, it is clear that he has a special love for the VIC-20; so it's completely understandable why he uses it as a foundation. Yeah 8BG needs no defending, but I grok it. If I were an engineer* I might've started with the PET, for the same gut-reason that that's the first computer I learned on (although it does actually look like the VIC is a better starting place). * I'm comp. sci. It may be in the engineering college, but...
  7. Ok, that sounds useful. I've done I2C but not SPI, so I'll start reading. There's also the UART (pins 8 and 10 / GPIO 14 and 15).
  8. I've thought about this very generally, and figured that to a large degree, data can be buffered in RAM on the storage device until transmission is done. Since the X16's RAM footprint is small, a Pi buffer might remove any potential flash lag. *** ^ Given. So I wrote a simple one-wire noiseless no-ack ("SOWNONO") protocol between two Pi Zeros, in C, using WiringPi, on Raspbian. It looks like I can get a whopping 500 bits per second. In theory, then, plain old C with wiringPi and no ACK can get me 62 bytes per second. No optimizations, no special nothing, and of course once they go out of sync it's disaster. But it was fun to write and is a start. *** I think if I revisit my simple talker, I'll define a frame and add an ACK. I've seen a Michael Steil video where communication can slowly drift out of sync over dozens of bits... But I'm also thinking about using my Arduinos -- I've got a Nano and a Mega 2560.
  9. Sounds a lot like how I managed virtual Commodore disk images. Thanks for the good suggestion!
  10. I had thought about a true hashed structure, with pointer-like things. A "pointer" could be broken down into two parts like this: typedef struct { int offset : 13; // inside bank (13 bits = 8192 bytes) int bank : 3; // eight banks, max 64K RAM. } BANKED_HASHMAP_POINTER; So then, navigating through a BANKED linked list of hash entries is a matter of (a) setting the bank and then (b) heading to the offset (0xa000 + offset). Then two more bytes to hold a cheap hash value. Four bytes overhead per pair isn't bad. A thousand entries = half a bank is devoted to overhead. Hmm well that doesn't sound great but meh. The memory management code might be a little more involved.
  11. I'm just being lazy. I've got two other algorithms -- one stolen from Perl -- that create bona fide linked and hashed ... uh, hashes. I just get the feeling that I can do this in a more primitive way in order to leverage banked RAM and totally minimize system RAM. Maybe - ha!
  12. Here's the fuzzy problem: I'm slowly writing an interpreter for the X16, and I therefore need a symbol table. HOWEVER, I can't really guarantee that I'll have much system RAM for neat data structures. So I'm looking at the banked RAM to store my hashtable. ALL of it if possible. THAT has implications ... for example I don't think malloc() and free() are really going to work in banked RAM. SO: *** I'm trying a "cheap" banked string map implementation using a list. The idea is to have a small, slow, symbol table (less than 1000 entries, spanning several RAM banks) with a minimum of management code (and a minimum of system RAM). It doesn't even hash. I understand that it will be slow and linear. That's OK. My thoughts go like this: RAM bank memory can be chopped up into 256 segments like this: typedef struct { unsigned char header; char data[31]; } BANK_LIST_SEGMENT; BANK_LIST_SEGMENT* bank_list[256]; // = 8192 bytes = 1 bank. Key:Value entries are segment-aligned: the shortest mapping is 32 bytes, and the increment is 32 bytes, to a max of 288 bytes. I'll try ways to optimize this -- for example, reducing the segment length to 24 bytes. Or scrapping it for dynamic memory management, since this is a solved problem... especially if code size doesn't really change.... I can run through the list and check the first byte of each segment. If it's a zero, then that hunk of 32 bytes is unallocated. If it's a printable PETSCII, then it's allocated and part of the current pair. If it's 1 thru 31, then it's a new pair, and the key length is given (1-31 characters), so I know where the value string starts. (Or I can limit it to 30 chars, with a "31" indicating the start of the value string of the current pair for convenience.) Keeping the key length known AND under 32 characters lets me do strncmp's safely (?). I may have a problem with values if they don't end in zeros -- so I have to make sure then end in zero. This may have length implications, especially if the zero intersects with byte zero of the next segment. That means I'll have to store the length of the value string, which OK FINE. Maybe this has already been done in a better way already. I know hashes have been done-to-death in various ways. Thoughts?
  13. This has made me want an Open_Kernal even more, and I'm not quite sure why...
  14. I think I noticed this, too. A PET font that I like to load, doesn't appear to... I think. If there's a problem with file loading, then I've gotta wait as well, since I usually have LOTS of data files I heft into banked RAM.
  15. cc65's gotoxy() works in r39 -- I tried that and then did a stdio printf(). In fact I also did a revers(1) and printf() and it printed reversed text. So it's perhaps just the cputc() cputs() cprintf() that's wonky -- in other words, the text frame location thingy is off.
  16. I have r39 installed, but cc65 has some tweaks to do before I move to it. I've encountered a problem somewhere in conio.
  17. No. cc65's cputc(), cputs(), and cprintf() appear to be non-working for X16.r39. Text frame address change?
  18. The problem appears to be with conio -- cprintf(), cputX(), etc. The stdio outputs work -- printf, puts, etc. libsrc/cx16 doesn't have its own conio, but it does have its own cputc... which seems to be perfectly fine, no VERA addresses stored there I think. ...and yet, cputc('x') does not output character 'X' to the screen (or anything that I can tell). More interesting, cgetc() appears to hang. Since conio does "direct videoram access", it makes sense that an address somewhere might need updating.
  19. I think sprites are ok -- I can see one, so I assume they're good -- but some address gets jostled around somewhere so that printf, cprintf, and the various .put.() fail. I'll dig around and look for an old address.
  20. I found that r39 wouldn't print text with one two three four any of my C programs. Make clean, make all, run. No text. Not quite NO text: It prints text with one of my programs.... until it clears the screen the second time, then no more. The programs still work fine on r38, so it's a change in the emulator, one way or the other. Ah, my bank switching updates location $00 AND $9f61... not great, but also not the problem (I comment out that line, and I get the same results). I'm also not sure it's loading the font file like it did before (that is, it's not working, or perhaps it's working differently). Hm, it also doesn't seem to be showing my sprites. So I'm probably not doing something correctly. ...On the other hand, it runs one of my BASIC programs perfectly fine, and that has PSG sound and sprite data it manually transfers into VERA. So I would say the problem is not with the VERA emulation.
  21. Gotta have Catalina. I upgraded just so I could run the r39 binary. I thought about building, but got lazy.
  22. Uh oh! Let's find out if my code is banking correctly!!
  23. I have a 400K data file I load into banked RAM. I've adapted nicely to using banks -- I can externalize a lot of data that way.
  24. At the time of that video, I wonder if the system used Bank 0 yet? If not.... I wonder if I/O could be shoved into an upper slice of Bank 0. On the other hand, that would make I/O less friendly. Although it could enable a 256 byte window into VERA.
×
×
  • Create New...

Important Information

Please review our Terms of Use