Jump to content

aex01127

Members
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

aex01127's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Thanks for your reply. I had to spend a bit time on research before replying back to you. I agree that the scope I presented was a bit vague. What I want is to enable communication with a faster device using the I/O area. This faster device is a SoC of some kind that can provide stuff like wireless connectivity etc. All IO access is initiated from the X16 side. So in this setting the X16 would be the slow device. The decoding of the address bus (from 16 bits down to 5 bits + CS) will be handled in hardware. When I was thinking about trying to implement this is software I wanted to use a much faster system in the GHz range, like a Raspberry Pi Compute Module 4. I would need 5 pins for addressing, 8 pins for data and then a few for system (CS, clock, RWB). Using a 1,5GHz CPU would give a clock cycle on 0,67ns, compared to 125ns. I tought it was possible to manage this in code. I have spent some time reading and trying to understand CPLD and FPGA. CPLD seems (in theory) fairly easy to implement, and I have some ideas to work on. FPGA seems somewhat harder to implement but gives me more options that I am not sure I need. For both of these solutions the main issue is how to develop and "compile" the code. The toolchain needed often seems to cost lots of money with a few exceptions. Documentation and examples on now to develop is hard to come by. I could not find what model of FPGA is used for Vera. If I want to look further into this it would be nice to at least try work with the same vendor that is used by Vera. Should we think about a "reference design" on how to connect an expansion cartridge using CPLD og FPGA? I think some would come from how Vera is designed / programmed and can't wait for the schematics and code to be published.
  2. I think a loader like this is a good thing to have. I know I can make it up by separating each bank into separate files, but then I need to redistribute several files to accomplish the same goal. One file is much cleaner and safer. The ROM portion of this will not be much as the ROM loader only will handle the segments that the loader can handle. The limit we have today with the PRG files is that it has to fit into memory. The ability to have the usercode also work with the file is a plus (loading additional resources). For me it is not that important but as since there does not seem to be any extra cost (complexity/code) for the ROM based loader I think this is a good addition. It can make things easier for some people. I also think that a relocatable file creates too much complexity/overhead and is not needed (at least for most use cases). My vote is on this project.
  3. I am not sure how to proceed if I want to try do something to work with the IO bus with chips or other electronics that have a different format. Could you give me some ideas about what to search for or look after in order to do so? Using a much faster CPU (on the other end) will not manage to deal with the signalling so that a program can manage the expansion slot in real-time?
  4. I had a quick look through the spec. I think somehting like this deserves a thread on its own. A kind of loader that can write into various memory locations and also handle memory banks / IO is useful to have. There are some parts that I quite not understand here. Is it meant that the loader runs after the program has started? As block type $10 seems to be something where the player and the loaders works together. Also, the spec should define where the config block is loaded to memory, so it does not overlap with existing code. As for the PC side (compiler) instead of writing in many languages you could look into golang, you can write one implementation that can run on all platforms. As for the reference loader I guess the ultimate goal is to get it into the ROM - so assembly is perhaps the only way to go?
  5. The PRG format is just your code prefixed with two bytes that is the load address. I have not seen anything that does this directly on the computer, and as most programs are memory constrained I you look at the CC65 toolchain there is a linker that does relocation. It allows you at link time to change placement of the code. It also supports banking so you can write code (or data) in to several banks.
  6. The heap comes right after the BSS segment that is the last part of the program. __HIMEM__ is defined as $9F00 on the X16. And CC65 allocates by default 2K for its own stack right before HIMEM. So $9F00-$0400-END_OF_BSS is what you have as available memory. My testprogram above ends at $1802. That gives me about 32k of usable memory. ($82FE to be exact.) This is also confirmed by the program above that manages to allocate approx 32k. On the C64 the ROM is mapped out so you get almost 55k of usable RAM.
  7. I would really recommend looking into CC65. I think it has everything you ask for. If you work on small projects you can have everything in one file. And if you want to work on larger projects you will also see that it scales. Linking together multiple files, combining assembly / C language. The options are endless. I also see that CC65 is used for building the X16 kernal / Basic. cc65 is also available on most modern operating systems using packet managers. To compile a simple program I would use something like this: cl65 --cpu 65C02 mylife.s -t cx16 -C cx16-asm.cfg --start-addr 16384 Load your program and SYS16384 to get it started. Attached is Hello World using Vera. Edit: I misread that you wanted it to run on the X16. So my answer does not apply. hellow.s
  8. I gave malloc a shot and it seems to work on both X16 and C64. Example code below. void try_malloc() { unsigned int total = 0; char *str[15]; unsigned char i; unsigned int m_size = 3000; const unsigned char reps = sizeof(str) / sizeof(str[0]); // allocate memory 1. run for(i = 0; i < reps; i++) { str[i] = malloc(m_size); if(str[i] != NULL) total += m_size; printf("Alloc %u: %04X (total %u)\n\r", (unsigned int)i, str[i], total); } // deallocate half for(i = 0; i < reps; i++) { if (str[i] != NULL && i % 2 == 1) { printf("Free %u: %04X (total %u)\r\n", (unsigned int)i, str[i], total); free(str[i]); total -= m_size; } } // allocate memory 2. run m_size = 2000; printf("malloc size: %u\r\n", m_size); for(i = 0; i < reps; i++) { str[i] = malloc(m_size); if(str[i] != NULL) total += m_size; printf("Alloc %u: %04X (total %u)\n\r", (unsigned int)i, str[i], total); } }
×
×
  • Create New...

Important Information

Please review our Terms of Use