I'm working on a rather ambitious project of creating a ROM and FDC controller emulation for Amstrad CPC using a PIC 18F46Q10 . In the process,i use many tables for placing various codes (for example i've a 16k table that holds the entire amsdos ROM in a table). Now, it seems that whenever i'm trying to incorporate more than 3 large tables (each containing thousands of byte elements) and/or more than 15 tables, and although it seems that code is compiled without problems (no error in flashing process or anything), PIC program doesn't seem to work right, incomplete or partial table reads (where it should read the hole table) or even crashes and hang ups of amstrad! All these symptoms dissapear when i have less than 15 tables in total ,and less than 4 large tables.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the latest code. It's rather big, and it gives the best results. It seems that everything works ok, except the "Terminal" table. This table is the latest addition in code, it contains a hole basic lisitng which is fetched from PIC's table to amstrad's RAM when i give a specific RSX command. The problem is that basic listing is not completely transferred, like there is a partial read of table for some reason.
I just compile it:
Compiler Version (YYYY-MM-DD): 0.98.06 2019-06-12 (Windows 32 bit) Program Memory: 25374/32768 words (77,44%) RAM: 3589/3615 bytes (99,28%) Chip: 18F46Q10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. The latest compiler must use a few bytes more as the Buffer would need to be reduced to 3256bytes, or, we figure out where the bytes have gone.....
But, there is nothing obvious in your program but you are using a Q10. So, look very very carefully at the interrupt routine/handler. Is the compiler caching ALL the required variables?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just tried to incorporate the "terminal" table into the 1st "Rsx" table, which now has become ~15k. Unfortunately this gives much worse problems: most of commands are not working at all!
The "Rsx" table works perfect when it's ~10kbytes in size, but completely crashes when it become ~15kbytes ....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No unfortunately reducing buffer doesn't seem to help.
I've made a few more tests and it seems that there is a problem in reading correctly big tables of many thousands elements or/and many tables in the code. Is there any compiler limit regarding the size and the number of tables one can use in a cow basic program?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no limitation on the 18F that I am aware of.
I would need a time to review your code to try and work it out. But, meanwhile how many elements are in the tables? And, can you change the integer you are using to address the table - change to a word please (make other changes to support this change)
Are you calling the table reads during the interrupts ( I think you are not) ? Is this Q10 chip similar to the K42/K83 with respect to interrupt handling (these are very different from all 18fs before)? Does the Q10 have any specific features that require additional caching handling during the interrupt routine?
I am suspecting the interrupt handling as this would be the first place I would look.
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reduce the size of "terminal" table ~1000bytes, and now everything works perfect!
Q10 have their own manual, but they are pin compatible with K42 (my first experiments were with k42) and cowbasic code worked almost straight away by just changing the chip declaration at start. I use Q10 version because i need the 8CLCs (with 8 pps inputs) in order to implement the required logic(address decoding, enable/disable of pic code, pause/unpause amstrad etc) into pic and not use extra discrete logic for that.
I'll try to change the variable i'm using for table pointer to word and see if that works.
Thanks again for your interest and suggestions!
p.s. i just remembered, for some reason, i wasn't able to use hardware serial port 1, it crashed from start up, but everything works ok with serial port 2...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The serialport1.gcb use hardware serial port1, i use these settings:
RXPPS = 0x0009 'RB1 > RX1
RB2PPS = 0x0009 'TX1 > RB2
'#define USART_BAUD_RATE 1065600
' #define USART_DELAY 0 ms
On Interrupt UsartRX1Ready Call readUSART
And also commands Hserreceive and hsersend x. Unfortunately this code has two major problems:
- Using usart1, amstrad can't boot, unless the serial port is connected to pc (with usart2 it doesn't matter, it works fine either if serial port is connected or not at boot)
Hsersend seem to work ok, but hserreceive doesn't seem to receive any bytes sent from pc, it's like the interrupt routine doesn't work with usart1.
I've also attached the 18f46q10 datasheet in case it might be useful to you.
Hope these will help resolve the issues.
Yes! That's it!
I add the missing "1" in the PPS declaration of the RX1 pin, and both problems solved!
Amstrad boots withoput problems and can receive data from serial port without problems too!
Thanks again Evan for your intereset and help.
When i finish the project i might make a small "presentation" in the "User Submitted Projects, Demos & Guides", this might be the bigger project made using an adavanced 18FQ10 series PIC and cow basic :-)
Last edit: ikonsgr74 2020-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so if using a non programable pin device this would not happen , maybe?
is pps pin declaration a blessing or a curse?
personally don't like as it's a pain to set up even with tools. data sheets...don't understand them...that's why I use gcb, it's supposed to dumb down coding...not make it more complicated.
sorry,hate pps.
Was the answer to the post that tables depend on memory or what?
ps.Why is anyone using an amstrad cpc? after 40 years they still work?
Last edit: stan cartwright 2020-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well,i don't know if pps is "curse", but "unfortunately", it's mandatory if you want to utilize some more adavnace features of a modern PIC. For example,in order to use CLCs (configurable logic cells, they are small programmable logic modules which can be pretty useful for address/data/signal decoding in order to avoid using extra logic chips) there is no other way of assigning inputs and outputs to a logic cell, other than pps. pps also can be VERY useful from a pcb design perspective, the ability to "move" various functions into different pins than default, can help to make smaller and less "messy" boards too! ;-)
About the tables you ask, after many tests and trials i've concluded that there is definetely some kind of "limit" regarding the size and number of tables used in a project. Using ~15tables, with half of them having many thousands of elements (up to ~16000) (and using a rather "difficult" and advance PIC like 18FQ10 series), maybe i "push" the compiler a bit more than it can handle :-)
As for your question about "anyone using a cpc today", i can assure you that after Amiga (and maybe C64) Amstrad CPC must have the most ALIVE, vivid and creative community/scene in the planet! Software, games, hardware projects are constantly made and used by 1000's of amstrad cpc fans all over the world! For example, a couple of years ago, more than 60 new games presented for amstrad cpc in just ONE year, many of them surpassing "proffessional" games of the era!
And i have a feeling that lately, Rertro home computers have become again "trendy" and "Fashioned", even for younger people that didn't live the 80's ;-)
In 2 words:
Smart phones for stupid people....
Amstrad CPC for SMART people!
And of course, REAL man do it... 8bit with cowbasic! :-))))
Last edit: ikonsgr74 2020-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The CPC 464 and the one with a floppy drive were OK but no hardware graphics was a pain.
I wrote a sprite routine for cpc and the z80 ldir shifted data fast but scrolling the screen was visible. It did have palette switching though.
Locomotive basic was rather good. I preferred it to bbc basic.
Chris Roper is working on a DoEvery function for gcb after I suggested the amstrad basic function.
I had an amstrad "pc" to use when I did an OU degree course using drdos or msdos and a suite called frameworks. Heady days :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
True, amstrad cpc didn't have any hardware graphics acceleration (like c64's sprite engine), BUT it was equipped with the 6845CRT controller, which in fact had some hardware capabilities, and with smart code programming you could do things that seemed "impossible"!
For example, check this: https://www.youtube.com/watch?v=03xGJO_jXu4
Who said that only amiga could have smooth paralax scrolling in a game? :-)
Perfect scrolling, big sprites, smooth movements and in game music too! First time i saw this, thought it was a mock up from atari st :-)
Unfortunately this level of "mastering" amstrad's hardware, happened only in recent years , back at the "good old days", amstrad cpc suffered from a severe illness named... " SPECTRUMPORT-ITIS", e.g. many, many games were ported from much inferior spectrum hardware (only because was rather easy due to the same Z80 cpu...) .... :-(
Last edit: ikonsgr74 2020-07-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought your examples poor. Software graphics were always sad.
If you had the memory, you could switch screens ie do graphics on one screen while displaying another then change a pointer to display the other screen...I seem to remember.
To keep costs down they went the same way as sinclair and used a ULA which slowed things down
but I suppose it gave you more kit for your money.
I liked the effect of drawing horizontal lines that looked like going into the distance and vertical
lines that come from the top of the middle of the screen to wider points on the bottom of the screen, all different colours.
Then make all colours background and just change each colour in sequence to make the "land scape"appear to come forward and left/right keys can change the colours of the vertical to make them "scoll" left/right.
map a sprite to the screen and you have a simple but impressive 3d moving landscape.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you think that the 2 games noted, are... "poor examples", then i'm afraid you have REALLY forgot how CRAPPY scrolling and animation usually was in amstrad games (especially compared to C64, thanks" to SPECTRUMPORT-ITIS" for the most part...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any news about the table management problems with 18FxxQ10 PICs?
Btw, Microchip released even newer 18FxxQ43 series, these are not yet supported in latest cowbasic 0.98.06 release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm working on a rather ambitious project of creating a ROM and FDC controller emulation for Amstrad CPC using a PIC 18F46Q10 . In the process,i use many tables for placing various codes (for example i've a 16k table that holds the entire amsdos ROM in a table). Now, it seems that whenever i'm trying to incorporate more than 3 large tables (each containing thousands of byte elements) and/or more than 15 tables, and although it seems that code is compiled without problems (no error in flashing process or anything), PIC program doesn't seem to work right, incomplete or partial table reads (where it should read the hole table) or even crashes and hang ups of amstrad! All these symptoms dissapear when i have less than 15 tables in total ,and less than 4 large tables.
Any ideas?
None. Best send the source program to use to review.
Here is the latest code. It's rather big, and it gives the best results. It seems that everything works ok, except the "Terminal" table. This table is the latest addition in code, it contains a hole basic lisitng which is fetched from PIC's table to amstrad's RAM when i give a specific RSX command. The problem is that basic listing is not completely transferred, like there is a partial read of table for some reason.
What version of Great Cow BASIC? I am getting a compile error.
I just compile it:
Compiler Version (YYYY-MM-DD): 0.98.06 2019-06-12 (Windows 32 bit) Program Memory: 25374/32768 words (77,44%) RAM: 3589/3615 bytes (99,28%) Chip: 18F46Q10
OK. The latest compiler must use a few bytes more as the Buffer would need to be reduced to 3256bytes, or, we figure out where the bytes have gone.....
But, there is nothing obvious in your program but you are using a Q10. So, look very very carefully at the interrupt routine/handler. Is the compiler caching ALL the required variables?
I've just tried to incorporate the "terminal" table into the 1st "Rsx" table, which now has become ~15k. Unfortunately this gives much worse problems: most of commands are not working at all!
The "Rsx" table works perfect when it's ~10kbytes in size, but completely crashes when it become ~15kbytes ....
Hmmm, so you say that if i reduce the serial port buffet to ~3256 instead of 3500 the problem will solve?
I was just sharing the memory buffer would have to be smaller with the new compiler.
That is a large buffer. Have you tried a smaller buffer and does this resolve the issue?
No unfortunately reducing buffer doesn't seem to help.
I've made a few more tests and it seems that there is a problem in reading correctly big tables of many thousands elements or/and many tables in the code. Is there any compiler limit regarding the size and the number of tables one can use in a cow basic program?
OK it was worth a try to reduce the buffer.
There is no limitation on the 18F that I am aware of.
I would need a time to review your code to try and work it out. But, meanwhile how many elements are in the tables? And, can you change the integer you are using to address the table - change to a word please (make other changes to support this change)
Are you calling the table reads during the interrupts ( I think you are not) ? Is this Q10 chip similar to the K42/K83 with respect to interrupt handling (these are very different from all 18fs before)? Does the Q10 have any specific features that require additional caching handling during the interrupt routine?
I am suspecting the interrupt handling as this would be the first place I would look.
Evan
I reduce the size of "terminal" table ~1000bytes, and now everything works perfect!
Q10 have their own manual, but they are pin compatible with K42 (my first experiments were with k42) and cowbasic code worked almost straight away by just changing the chip declaration at start. I use Q10 version because i need the 8CLCs (with 8 pps inputs) in order to implement the required logic(address decoding, enable/disable of pic code, pause/unpause amstrad etc) into pic and not use extra discrete logic for that.
I'll try to change the variable i'm using for table pointer to word and see if that works.
Thanks again for your interest and suggestions!
p.s. i just remembered, for some reason, i wasn't able to use hardware serial port 1, it crashed from start up, but everything works ok with serial port 2...
OK. Re table.
Can you create a simple Q10 HserPrint program to show the issue?
Ok,i've made two small codes, with only basic hw serial port function.
The serialport2.gcb use hardware serial port2 and seems to work ok, i use these settings:
RXPPS = 0x0009 'RB1 > RX1
RB2PPS = 0x0009 'TX1 > RB2
'#define USART2_BAUD_RATE 1065600
' #define USART2_DELAY 0 ms
On Interrupt UsartRX2Ready Call readUSART
Hserreceive2 and hsersend x,2 seem to work fine.
The serialport1.gcb use hardware serial port1, i use these settings:
RXPPS = 0x0009 'RB1 > RX1
RB2PPS = 0x0009 'TX1 > RB2
'#define USART_BAUD_RATE 1065600
' #define USART_DELAY 0 ms
On Interrupt UsartRX1Ready Call readUSART
And also commands Hserreceive and hsersend x. Unfortunately this code has two major problems:
- Using usart1, amstrad can't boot, unless the serial port is connected to pc (with usart2 it doesn't matter, it works fine either if serial port is connected or not at boot)
I've also attached the 18f46q10 datasheet in case it might be useful to you.
Hope these will help resolve the issues.
There may be an error in the PPS - line28 should read
Last edit: Anobium 2020-07-13
Yes! That's it!
I add the missing "1" in the PPS declaration of the RX1 pin, and both problems solved!
Amstrad boots withoput problems and can receive data from serial port without problems too!
Thanks again Evan for your intereset and help.
When i finish the project i might make a small "presentation" in the "User Submitted Projects, Demos & Guides", this might be the bigger project made using an adavanced 18FQ10 series PIC and cow basic :-)
Last edit: ikonsgr74 2020-07-07
Excellent news - and I look forward to the 'presentation!'
I'm looking forward to seeing this too. It is an intriguing project.
so if using a non programable pin device this would not happen , maybe?
is pps pin declaration a blessing or a curse?
personally don't like as it's a pain to set up even with tools. data sheets...don't understand them...that's why I use gcb, it's supposed to dumb down coding...not make it more complicated.
sorry,hate pps.
Was the answer to the post that tables depend on memory or what?
ps.Why is anyone using an amstrad cpc? after 40 years they still work?
Last edit: stan cartwright 2020-07-07
Well,i don't know if pps is "curse", but "unfortunately", it's mandatory if you want to utilize some more adavnace features of a modern PIC. For example,in order to use CLCs (configurable logic cells, they are small programmable logic modules which can be pretty useful for address/data/signal decoding in order to avoid using extra logic chips) there is no other way of assigning inputs and outputs to a logic cell, other than pps. pps also can be VERY useful from a pcb design perspective, the ability to "move" various functions into different pins than default, can help to make smaller and less "messy" boards too! ;-)
About the tables you ask, after many tests and trials i've concluded that there is definetely some kind of "limit" regarding the size and number of tables used in a project. Using ~15tables, with half of them having many thousands of elements (up to ~16000) (and using a rather "difficult" and advance PIC like 18FQ10 series), maybe i "push" the compiler a bit more than it can handle :-)
As for your question about "anyone using a cpc today", i can assure you that after Amiga (and maybe C64) Amstrad CPC must have the most ALIVE, vivid and creative community/scene in the planet! Software, games, hardware projects are constantly made and used by 1000's of amstrad cpc fans all over the world! For example, a couple of years ago, more than 60 new games presented for amstrad cpc in just ONE year, many of them surpassing "proffessional" games of the era!
And i have a feeling that lately, Rertro home computers have become again "trendy" and "Fashioned", even for younger people that didn't live the 80's ;-)
In 2 words:
Smart phones for stupid people....
Amstrad CPC for SMART people!
And of course, REAL man do it... 8bit with cowbasic! :-))))
Last edit: ikonsgr74 2020-07-07
The CPC 464 and the one with a floppy drive were OK but no hardware graphics was a pain.
I wrote a sprite routine for cpc and the z80 ldir shifted data fast but scrolling the screen was visible. It did have palette switching though.
Locomotive basic was rather good. I preferred it to bbc basic.
Chris Roper is working on a DoEvery function for gcb after I suggested the amstrad basic function.
I had an amstrad "pc" to use when I did an OU degree course using drdos or msdos and a suite called frameworks. Heady days :)
True, amstrad cpc didn't have any hardware graphics acceleration (like c64's sprite engine), BUT it was equipped with the 6845CRT controller, which in fact had some hardware capabilities, and with smart code programming you could do things that seemed "impossible"!
For example, check this:
https://www.youtube.com/watch?v=03xGJO_jXu4
Who said that only amiga could have smooth paralax scrolling in a game? :-)
Another examplpe is this:
https://www.youtube.com/watch?v=_Te8Qj7oRQE
Perfect scrolling, big sprites, smooth movements and in game music too! First time i saw this, thought it was a mock up from atari st :-)
Unfortunately this level of "mastering" amstrad's hardware, happened only in recent years , back at the "good old days", amstrad cpc suffered from a severe illness named... " SPECTRUMPORT-ITIS", e.g. many, many games were ported from much inferior spectrum hardware (only because was rather easy due to the same Z80 cpu...) .... :-(
Last edit: ikonsgr74 2020-07-10
I thought your examples poor. Software graphics were always sad.
If you had the memory, you could switch screens ie do graphics on one screen while displaying another then change a pointer to display the other screen...I seem to remember.
To keep costs down they went the same way as sinclair and used a ULA which slowed things down
but I suppose it gave you more kit for your money.
I liked the effect of drawing horizontal lines that looked like going into the distance and vertical
lines that come from the top of the middle of the screen to wider points on the bottom of the screen, all different colours.
Then make all colours background and just change each colour in sequence to make the "land scape"appear to come forward and left/right keys can change the colours of the vertical to make them "scoll" left/right.
map a sprite to the screen and you have a simple but impressive 3d moving landscape.
If you think that the 2 games noted, are... "poor examples", then i'm afraid you have REALLY forgot how CRAPPY scrolling and animation usually was in amstrad games (especially compared to C64, thanks" to SPECTRUMPORT-ITIS" for the most part...)
Any news about the table management problems with 18FxxQ10 PICs?
Btw, Microchip released even newer 18FxxQ43 series, these are not yet supported in latest cowbasic 0.98.06 release.