Jump to content

hth313

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

7 Neutral

Recent Profile Visitors

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

  1. Very promising, however I find the high pitched fragile synthetic tone (I do not know how to describe it) very annoying. I want more a heavy metal tune.
  2. "SysReq/PrtSc, Scroll Lock and Pause/Break", I have never used those keys and in most cases cannot imagine what they do, LOL The only thing that bothers me is that it puts the CTRL key down in the corner, which is a stupidity introduced by PC. Old UNIX keyboards (terminals) and my current (Happy Hacking) keyboard put it where the never used SHIFT LOCK is located on the X16 keyboard. Even the Commodore 64 got it in a better position (TAB) than down in the corner. Having it down there means I need to twist my hand to reach it, and I use that key a lot. It is actually very annoying to me, but I guess that I am the minority. (Rant off)
  3. I do not care so much of having CP/M on the X16, I would get a dedicated machine for that and they are not too pricey. What I do care about is having a proper serial port. Not having that is a huge turnoff for me. Would at least be possible to have it in the motherboard design even if it is not populated? I have one or two 6551 in my stash, there are new serial adapters using Rockwell 6551 sold on Ebay for the C64, not sure where they are sourced from.
  4. I used the BASIC that came with the C64 and C128 back in the day and while they can be used for various things, they quickly fall short and I abandoned them for Forth and assembly. With the X16 I will not even bother to try the BASIC, I will go to C and assembly instead. I wish it could boot into Forth and I could choose to play in that environment, or just load (C or assembly) software, then I would be very happy. Another alternative would be Scheme, I am not sure how feasible that is? My little 8-bit Lisp machine..
  5. Did not the PDP-11 do this 50 years ago?
  6. Is there some special considerations to be made if I want to pick up some YM2151 chips online? Given the shipping cost it seems sensible to buy at least 10. The reason for buying them is to ensure I have some spares if the stocks run out or low causing price to go up significantly.
  7. @desertfishThank you for the suggested way of going back to the Kernal. I have added that as the fallback way of doing explicit exit(), which is useful if the program has messed things up too much and want to exit back to a clean machine.
  8. I changed the C startup code to simply use the existing stack as-is. This solves the problem and I now get back to the blinking prompt when main() returns. I also took the opportunity to optimize it to the metal, more or less. I still have a proper C startup for the X16, but I changed the C code to be more like how I would write a Hello World in assembly, using a loop to send it to a character out routine, no printf() or stream related functions dragged in from the C library, no 0 exit code return either. The result is a C program that when compiled and linked results in a .PRG file that is 88 bytes.
  9. To be honest, an 8-bit like the 6502 is not at all about compact code, perhaps not even elegant. You will get much nicer instruction set if you move to the MSP430 or 68000. Even something like the RISC-V may be considered elegant compared to the 6502. An interesting approach would be to join something like Vera with a nice 16 or 32-bit based instruction set CPU. However, you would have to start from scratch with the "operating system" and the group of people interested in a 6502 computer would have to learn a new ISA, and somehow I think you would lose most of the audience along the road. I am not saying it is a bad idea. If the X16 is successful, it may make sense to produce a follow up going to a more modern ISA. It could have the same chipset (more or less). If people avoid 6502 assembly as an implementation language (there are BASIC, C, Forth etc), some software may be possible to migrate with reasonable effort.
  10. The problem is that I take over and set my own stack. I also put some stuff in zero page, but that should be in permitted and safe area (so far). What I am looking for is some soft-reset entry point back to BASIC that leaves the display and program. It should perhaps clear variables and sets up the stack again. Perhaps I should not touch the CPU stack at all?
  11. I just got my first output from my (own) C compiler and it was also among the first times I ever played with the X16 emulator, so I want to share my (minor) success. How should I exit from the program back to the system? Sorry if this is really a stupid question, but it was a long time ago since I programmed a Commodore 8-bit machine.
  12. Moving the bank registers to zero page only makes sense if it is also possible to read them. It is useful to allow calls between banks using a trampoline (bank switcher) in non-banked memory. Such trampoline needs to push the bank number together with the return address so that it later can return via another trampoline to the caller (switching the bank back). If reading is not possible, a shadow bank number could be written to RAM, but that would mean writing the bank twice which defeats the gain of having it in zero page.
  13. If seeking is not available then ELF is out. I do not think is practical to read several program header structures, not knowing how many they are. I still think it is a good idea to be able to load a file into memory and have banks populated automatically. Can someone explain how GEOS helps to load a banked program at power on when I get the READY prompt?
  14. I think a load format for banked data is very useful and it should be in the ROM. That way we can just load a file and have it placed in memory without having to re-invent the wheel by providing custom loaders. Does it prevent anyone from rolling their own? Not at all, you are free to load a plain binary and load data and program chunks from the file system as you see fit. I on my side prefer to have a binary file created by a tool and not need to bother how it gets loaded into memory, even when I need to use the bank system. I like the ELF format myself as it rather simple to use when the requirements are simple, yet it provides a lot of flexibility and can be quite expressive when needed. Most of the complexity comes when adding debug sections or linkable sections, but that is not what we are doing here. I will describe it a bit below to give an idea what it is and show that it actually have a lot of similarities to the proposed format. An ELF file has an ELF header that starts with a magic number (actually the string ELF) that identifies it as ELF. You only need to sanity check that it is 32-bit ELF, inspect the processor type and values related to program headers that describe where the program headers are in the file, their size and how many they are. Each program header describes a chunk of memory to be loaded. The headers appear after each other. A header can describe an area to be cleared, or it can point to actual raw data to be loaded and it can specify a start address. Thus, in a file you have: ----------------- ELF Header --------------- Program header 1 ---------------- Program header 2 ---------------- ... ---------------- Program header n ---------------- Load data ---------------- The file can also contain sections, mainly for debug or vendor specific stuff, but you totally ignore them. Even if sections are in the file, you will automatically ignore them when you use the file offsets to locate the program headers and data. For a banked system you could use a program header for each bank. The address is 32-bit so you can easily combine a bank number with the lower address. If you compare this to the proposed format you will see that the structure is very similar. The ELF header is 52 bytes (in 32-bit ELF) compared to 64 in the proposed format. Each program header is 32 bytes in ELF and 8 in the proposed format. The main difference is that in ELF the program headers are located after each other and contains a field that gives the file offset of the actual data. A loader can interpret relevant fields and do some simple sanity checking, it does not need to be any more complicated. Here is a rough load algorithm: Open file, read ELF header and check the magic number, sanity check some fields in the ELF header to see that it is 32-bit ELF, for 6502 and that there is at least one program header. Store number of program headers, the size and keep a pointer to the current one, initialize it with the offset of the first program header as given in the ELF header. Seek to the next program header, load it and inspect type, read start address (if program type), size, offset in file to actual data. Load raw data from file, if the specified area is larger than what is in file, fill the rest with zero. Step to next program header, decrement header counter, if more program headers then go to 2. Jump to the start address of the program. The main advantage of using an existing format like ELF is that it makes it possible to use other tools for inspecting and altering the executable file. It also avoids re-inventing the wheel again as someone already gave this some thought. We only need to specify how we use the format for the CX16.
  15. I think it would be a good idea to have a loader in ROM so that the machine natively can load large binaries as single files. Without looking much into it, my gut feeling is that unless there is a good reason for it, it is better to use an existing format, or a subset of one. One advantage is that we do not need to invent something new, we just have to specify (supplement) how an existing format is used for this purpose. Second, we can use already existing tools to inspect and do things with such files. For example, I use the ELF format in my tools and as a result I can use tools such as 'objdump' to visualize and inspect the files, and 'strip' to prune them afterwards.
×
×
  • Create New...

Important Information

Please review our Terms of Use