- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#91
Technical support - Hardware related / Re: 464 tape deck grinding on ...
Last post by Devlin - 15:00, 07 October 24In that case, what kind of grease should I purchase?
#92
NC100, NC200, PCW, PDA600 - the rest of the Family! / Using the UART of the NC100/20...
Last post by Prodatron - 14:00, 07 October 24I'm currently working on a mouse driver for the SymbOS port of the NC100/200.
I can't test this at home right now as I'm still looking for a way to write SRAM cards.
So Edo and I have to do remote testing, which is a bit annoying. His serial mouse shows nice and correct values in the NC terminal program, but somehow I can't get it to communicate properly with my driver code.
So I'm wondering if there are any source codes for the NC and the UART to receive data over the serial port?
I've read that parts of the ROMs have been disassembled, but I can't find anything like that.
Any hints would be very welcome!
I can't test this at home right now as I'm still looking for a way to write SRAM cards.
So Edo and I have to do remote testing, which is a bit annoying. His serial mouse shows nice and correct values in the NC terminal program, but somehow I can't get it to communicate properly with my driver code.
So I'm wondering if there are any source codes for the NC and the UART to receive data over the serial port?
I've read that parts of the ROMs have been disassembled, but I can't find anything like that.
Any hints would be very welcome!
#93
Applications (CPC and CPC-related) / Re: Which would be your desire...
Last post by PulkoMandy - 12:29, 07 October 24Hello,
I don't really care about which specific language, but I think there are not so many which can run well given the CPC limitations.
Regarding compiled languages, we have a decent choice of these already with BCPL, C, Pascal, and Modula-2. They are stretching the limits of what you can do on a CPC already. I don't expect anything better will come out. It's possible to use a RAM disk to speed up build time, and also write code with "overlays" that could be put into memory banks (so you can have apps larger than the base 64K of memory).
Even for cross-compiled ones, there are things like Cowgol or Turbo Rascal, so no need to spend more time in that area (for me at least).
On the interpreted/scripting languages side, it is not as nice. Basically the choices are BASIC (either the Locomotive one or a few others available for CP/M), and maybe FORTH, LISP or MOUSE. None of these are really compatible with modern structured programming. I think Python, Lua, and other similar ones are all too big (in their current implementations) to be practical.
That's why I'm looking into Smalltalk now. As a scripting language running in a virtual machine, it can make the memory banking largely invisible and handle it for you. So you can write your complicated algorithm and not worry about where to locate the data. Of course, as a downside of that, it will be rather slow (we'll see if it's just a bit slow, or unbearably slow).
A few other things to consider:
Projects like Java Grinder, which is a converter from JVM (Java Virtual Machine) bytecode to assembler. You could then use Java (or Kotlin or Scala or other languages using tje JVM) and convert to assembler. I don't know how efficient it is. Definitely for cross-compilation only.
I don't really care about which specific language, but I think there are not so many which can run well given the CPC limitations.
Regarding compiled languages, we have a decent choice of these already with BCPL, C, Pascal, and Modula-2. They are stretching the limits of what you can do on a CPC already. I don't expect anything better will come out. It's possible to use a RAM disk to speed up build time, and also write code with "overlays" that could be put into memory banks (so you can have apps larger than the base 64K of memory).
Even for cross-compiled ones, there are things like Cowgol or Turbo Rascal, so no need to spend more time in that area (for me at least).
On the interpreted/scripting languages side, it is not as nice. Basically the choices are BASIC (either the Locomotive one or a few others available for CP/M), and maybe FORTH, LISP or MOUSE. None of these are really compatible with modern structured programming. I think Python, Lua, and other similar ones are all too big (in their current implementations) to be practical.
That's why I'm looking into Smalltalk now. As a scripting language running in a virtual machine, it can make the memory banking largely invisible and handle it for you. So you can write your complicated algorithm and not worry about where to locate the data. Of course, as a downside of that, it will be rather slow (we'll see if it's just a bit slow, or unbearably slow).
A few other things to consider:
Projects like Java Grinder, which is a converter from JVM (Java Virtual Machine) bytecode to assembler. You could then use Java (or Kotlin or Scala or other languages using tje JVM) and convert to assembler. I don't know how efficient it is. Definitely for cross-compilation only.
#94
Well it was a little more than a few days...
Someone mentionned this in another thread so it's time for an update
I resumed work on the project last week. As mentionned in the previous post, I have removed again the indirection table, and went for objects directly referencing each other. This means:
I also updated to the latest nightly build of SDCC which has improved code generation a bit. This allows to fit more things in the ROM. The generated code is still not great, compilation times are ridiculous (at least 45 minutes to build 16K of code, up to 5 hours if I ask the compiler to optimize a bit more). Modern software...
The current result is:
There is no garbage collection yet and the interpreter creates a lot of temporary objects, which normally would be almost immediately deleted by the garbage collector. So the memory usage will be massively reduced when I implement that.
But I prefer to get "5 + 3" fully working before I move on to implementing garbage collection, so that I have a simple test scenario to test with. I have some ideas to achieve this. Also I should start rewriting the code in assembler directly (one function at a time) to make it smaller and more efficient. And even before doing that I have some optimizations to do in the C code that I apply manually (each new development requires finding a way to save space in the ROM for it).
At least initially, I may move the garbage collector to a separate ROM. The interface between the two parts of the code is currently 4 functions, but it can probably be reduced to 1 or 2 with extra parameters. So that provides a nice interfacing point to split the ROM in two. And maybe later I can optimize things enough to consider merging them again.
You can see some screenshots and day-by-day notes and milestones on my Fediverse account:
https://mastodon.tetaneutral.net/@pulkomandy/112107254263308680
Someone mentionned this in another thread so it's time for an update
I resumed work on the project last week. As mentionned in the previous post, I have removed again the indirection table, and went for objects directly referencing each other. This means:
- The pointers/references are 3 bytes (bank + address)
- The garbage collector will have a bit more work to do to update all references when moving an object
I also updated to the latest nightly build of SDCC which has improved code generation a bit. This allows to fit more things in the ROM. The generated code is still not great, compilation times are ridiculous (at least 45 minutes to build 16K of code, up to 5 hours if I ask the compiler to optimize a bit more). Modern software...
The current result is:
- The interpreter runs far enough to display the smalltalk prompt
- I can enter an expression in the prompt
- The compiler starts converting the expression into bytecode, but it runs out of memory (512K of banks + 16K of main memory are reserved for the object heap) before managing to compile and execute it (I just tried to run something simple like 5 + 3)
There is no garbage collection yet and the interpreter creates a lot of temporary objects, which normally would be almost immediately deleted by the garbage collector. So the memory usage will be massively reduced when I implement that.
But I prefer to get "5 + 3" fully working before I move on to implementing garbage collection, so that I have a simple test scenario to test with. I have some ideas to achieve this. Also I should start rewriting the code in assembler directly (one function at a time) to make it smaller and more efficient. And even before doing that I have some optimizations to do in the C code that I apply manually (each new development requires finding a way to save space in the ROM for it).
At least initially, I may move the garbage collector to a separate ROM. The interface between the two parts of the code is currently 4 functions, but it can probably be reduced to 1 or 2 with extra parameters. So that provides a nice interfacing point to split the ROM in two. And maybe later I can optimize things enough to consider merging them again.
You can see some screenshots and day-by-day notes and milestones on my Fediverse account:
https://mastodon.tetaneutral.net/@pulkomandy/112107254263308680
#95
Technical support - Hardware related / Re: 464 tape deck grinding on ...
Last post by Bryce - 09:09, 07 October 24Quote from: Devlin on 01:21, 07 October 24I don't have any grease to do that, but the problem started after changing the belts and doing nothing else besides a quick cable repair on the power led and switch, so i'm not thinking that's necessary just yet. I want to solve this problem first, and then I can look into further maintenance (and have future knowledge to stop this issue if it manifests again)
It's not further maintenance, it's a possible cause.
Bryce.
#96
Applications (CPC and CPC-related) / Re: Which would be your desire...
Last post by Bryce - 09:07, 07 October 24I'd like something like Scratch to get someone younger interested in programming on the CPC.
Bryce.
Bryce.
#97
Alongside big titles from Dinamic, a large batch of hits such as Gilligan's Gold and Fruity Frank ! Thank you 
#98
Applications (CPC and CPC-related) / Re: Which would be your desire...
Last post by poulette73 - 04:42, 07 October 24Quote from: xesrjb on 03:59, 07 October 24I would like Turbo Pascal...already exist in CP/M
#99
Applications (CPC and CPC-related) / Re: Which would be your desire...
Last post by xesrjb - 03:59, 07 October 24I would like Turbo Pascal...
xesrjb
xesrjb
#100
Barbarian, Arkanoid, DonkeyKong... any proper nonspeccyport, most modern homebrew games.