You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
2003 |
Jan
(22) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
(12) |
Oct
|
Nov
(6) |
Dec
(11) |
2004 |
Jan
(9) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(6) |
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(2) |
Jul
(31) |
Aug
(1) |
Sep
(7) |
Oct
(17) |
Nov
(24) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
(28) |
Apr
(7) |
May
(6) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(1) |
Dec
(9) |
2009 |
Jan
(4) |
Feb
(12) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(15) |
Nov
(23) |
Dec
(3) |
2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2016 |
Jan
|
Feb
(10) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(27) |
2017 |
Jan
(8) |
Feb
(6) |
Mar
(5) |
Apr
|
May
|
Jun
(24) |
Jul
(6) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(15) |
Nov
|
Dec
(6) |
2019 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Jason O. <wa...@gm...> - 2019-11-01 05:22:34
|
Hi. I figured rather than filling up the forum it might be better to ask here. I had this reply from Dom: ------ int i,j,fontdatastart,textchar; int fontoffset,arrayoffset; char fontarray[]; Which defines an array with 0 elements - i.e. it consumes no space on the stack. So you've got on the stack: sp+0 = fontarray sp+0 = arrayoffset sp+2 = fontoffset And then you've got: fontarray[0] = fontspec.width; fontarray[1] = fontspec.height; Which will overwrite array offset with the value 7 * 256 + 5 = 1797 ===== I want to understand when things get added to the stack and if it's not possible to declare an array but not set a size since it won't grow by pushing other variables down, but will overwrite other variables. Should I use malloc to set the array size since I don't know at the start how large the array size will need to be until a separate file with array data is read in? Does declaring fontoffset and arrayoffset not reserve the space of an int? Are arrays with no size declared not usable with z80 C programming? For other code reference, this is from: https://www.z88dk.org/forum/viewtopic.php?id=11050 I tried using malloc then got an error saying missing _heap so I read I need to declare "long heap" which I did, then I read I need "void mallinit(void)" and now my code doesn't run at all. Thanks. -- https://JasonOakley.com/ - Voice acting and geeky stuff <http://AussieTechHeads.com.au/> https://OziByte.com - Fitbit Ionic clock faces and games <http://AussieTechHeads.com.au/> http://AussieTechHeads.com.au/ - Australian technology podcast https://www.facebook.com/RetroRegeneration/ - My retro 80s radio show https://BlueBilby.com/ - My retro VZ200 website |
From: Tomaz S. (<tom...@wi...> - 2019-05-21 15:15:10
|
Hi, I was just wondering if there's anything new with relocation logic and embedding debug info into output files to help debuggers display C source code? I remember there was a discussion about .reloc files, which would help operating system loaders load Z80 code on any address and run it (not self realocation, but OS realocation), but then it went silent so I'm just wondering if anything was implemented? Also, in generated object and/or assembly files, are there C source code lines or source inserted so that debugger could read it and display it? |
From: Stefano B. (<ste...@ho...> - 2019-01-19 18:16:32
|
Most of the functions declared in graphics.h are now supported on all the targets with even a minimal graphics capability. I also added few more functions regarding boxes and rectangular areas. Similarly every target able to display monochrome sprites and have the minimal graphics support can use also those functions in games.h regarding sprites: bksave, bkrestore, getsprite... which are useful also to run gui related code (x11.h, hui.h..). |
From: Stefano B. (<ste...@ho...> - 2019-01-11 21:24:40
|
Inlined assembly can be enclosed in #asm / #endasm when using sccz80 or "__asm" / "__endasm;" when using sdcc. |
From: Stefano B. (<ste...@ho...> - 2019-01-11 21:23:08
|
Inlined assembly can be enclosed in #asm / #endasm for sccz80 or "__asm" / "__endasm;" for sdcc. |
From: rastersoft (<ras...@gm...> - 2019-01-11 12:55:39
|
Hi all: I want to inline some assembler with zsdcc, but it seems to not recognize the #asm and #asmend statements. The same code compiles fine with sccz80. How can I do that? I want to use zsdcc because the output code is much faster. Thanks. |
From: RobertK (<rob...@ps...> - 2019-01-09 13:51:58
|
Problem solved, thank you! Sure, you may put all my test programs on a repository. This screen switching test program still needs some #if #elif #endif for various targets (different mode numbers, some targets need clg() while others don't support it, etc.), but apart from that it is ready to be used. In my plot test program I will need to update the comments at the top, some of the issues mentioned there have already been solved. BTW, the platform list on the wiki also needs some updates (Galaksija hires graphics, maybe also PC-8001 for those parts that are already officially released). |
From: Dom M. <do...@su...> - 2019-01-08 22:03:55
|
On Tue, 8 Jan 2019, at 8:24 AM, RobertK (rob...@ps...) wrote: > However, I have found another issue that I could reproduce on both MAME > and the ZX-Uno. After switching back from graphics mode to text mode for > the first time, the text screen is no longer centered. Thanks for another great test program - do you have any objections if I actually commit them to the/a repo? I use pretty much all of them to test new platforms and behaviour. Who knows, one day I might be able to add a port without any bugs! I've reset some variables to the default values when the mode is switched back to text. One of them is HORIZ_POS ($2ba8) , and the other I really don't know it is, but since it's modified for hires mode it should be set back. As a result the display is now centred when switching between the modes. cheers, dom |
From: RobertK (<rob...@ps...> - 2019-01-08 08:24:49
|
The Hires Galaksija Plus version of H-Tron is already available on available on my Sourceforge site. Yes, using -lmath48 instead of -lm had indeed solved the floating point problem, my WIP program works fine now. However, I have found another issue that I could reproduce on both MAME and the ZX-Uno. After switching back from graphics mode to text mode for the first time, the text screen is no longer centered. Here is a test program to reproduce this: [code]// smt.c // Test program for screen mode switching on the Galaksija Plus and the NEC PC-6001 Mk2 // (also for MC-1000, Tiki-100 or Samsung SPC-1000, but not tested yet on these systems) // Author: RobertK, 2019-01-07 // Compile with: // zcc +gal -subtype=galaxyp -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:CRT_FONT=_font_8x8_bbc_system -o smtgalplus smt.c -D__GALPLUSHIRES__ // zcc +pc6001 -subtype=rom -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:CRT_FONT=_font_8x8_bbc_system -create-app -o smt_pc6001Mk2 smt.c #include <stdio.h> #include <graphics.h> #include <sys/ioctl.h> // required for switching the screen mode void myCls() // Clear the screen (generic or VT100 console) { printf("%c",12); printf("\x0c"); // the "\x0c" (0x0c character) resets the cursor position to the top left corner } void main() { int XScreenSize,YScreenSize; // dimensions of the text screen int xMax,yMax; // dimensions of the graphics screen int mode; // for screen mode switching int x,y; char c; // for keyboard input int exitProgram=0; // determine screen size screensize(&XScreenSize, &YScreenSize); /* main loop */ while(exitProgram<1) { // Text screen myCls(); // Clear the screen // Draw a screen border using the character "x" for (x = 0; x <XScreenSize; ++x) { gotoxy(x,YScreenSize-1); printf("x"); gotoxy(x,0); printf("x"); } for (y = 1; y <YScreenSize; ++y) { gotoxy(0,y); printf("x"); gotoxy(XScreenSize-1,y); printf("x"); } gotoxy(2,2); printf("text screen test"); gotoxy(2,4); printf("screen size: x=%d, y=%d\n",XScreenSize,YScreenSize); gotoxy(2,6); printf("press x to exit, any"); gotoxy(2,7); printf("other key to switch"); gotoxy(2,8); printf("to graphics mode..."); c = fgetc_cons(); // wait for keypress if (c=='x' || c=='X') exitProgram=1; else { // Graphics Screen // switch to hires mode mode = 1; console_ioctl(IOCTL_GENCON_SET_MODE, &mode); // clg(); // determine the screen dimensions for this system // coordinates go from 0 to this max value xMax=getmaxx(); yMax=getmaxy(); // Draw a screen border for (x = 0; x <=xMax; ++x) { plot(x,yMax); plot(x,0); } for (y = 1; y <=yMax; ++y) { plot(0,y); plot(xMax,y); } gotoxy(2,2); printf("graphics screen test"); gotoxy(2,4); printf("screen size: x=%d, y=%d\n",xMax+1,yMax+1); gotoxy(2,6); printf("press x to exit, any"); gotoxy(2,7); printf("other key to switch"); gotoxy(2,8); printf("to text mode..."); c = fgetc_cons(); // wait for keypress if (c=='x' || c=='X') exitProgram=1; // switch back to text mode mode = 0; console_ioctl(IOCTL_GENCON_SET_MODE, &mode); } } myCls(); // Clear the screen return; }[/code] And here is the result, first in MAME... [img]http://666kb.com/i/e07odqmeo43z2x30e.jpg[/img] [img]http://666kb.com/i/e07oe1t4j4wqfpqwu.jpg[/img] [img]http://666kb.com/i/e07oeafo5ioifvji6.jpg[/img] ...and here in FPGA on the ZX-Uno: [img]http://666kb.com/i/e07oehrj0uk3gvv5q.jpg[/img] [img]http://666kb.com/i/e07oeoiq7vqmt57r2.jpg[/img] [img]http://666kb.com/i/e07oeurzlw8odwtq6.jpg[/img] (On the second screen it should of course be "switch to text mode" instead of graphics mode, I didn't notice that error before I made the screenshots.) For some reason, on the FPGA in graphics mode only the top line of the screen border is visible. This could be a bug in the ZX-Uno Galaksija core, there can of course be errors in such an FPGA implementation just as in an any emulator. On the FPGA Galaksija Plus, when you type GRAPHICS and then TEXT, you briefly see the vertical full block line appearing, but then it goes away and the screen goes into position to the left again, so the characters are always at the same locations (you see their font changing) - probably the real hardware also behaves like that. |
From: Dom M. <do...@su...> - 2019-01-07 20:32:47
|
On Sun, 6 Jan 2019, at 10:50 PM, Dom Morris wrote: > genmath uses the index registers, and I think the Galksija reserves iy > for the video processing routine. I'll try it out myself, but switching > to math48 (use -lmath48 rather -lm) might unblock you there. Yup, that works - I've now switched the Galaksija over to using math48 by default. cheers, dom |
From: Dom M. <do...@su...> - 2019-01-06 23:07:49
|
On Tue, 1 Jan 2019, at 11:10 PM, RobertK (rob...@ps...) wrote: > I can confirm that the screen replication at the right edge is a Mame > emulation problem. I don't have the original hardware, but I tried it on > a ZX-Uno FPGA computer implementing the Galaksija Plus hardware, and > there everything looks good. That's good to know that it works outside of Mame! I think of the 3 games that supposedly support it, I only got one of them to work - hopefully you'll be releasing game number 4 soon! > I'm currently working on another little cross-platform program that will > make use of the full resolution, but I can't get it to work on the > Galaksija because of the floating point problem mentioned above > (calculating screen coordinates fails). genmath uses the index registers, and I think the Galksija reserves iy for the video processing routine. I'll try it out myself, but switching to math48 (use -lmath48 rather -lm) might unblock you there. > @Dom: you can speed up MAME emulation by pressing F10, and pressing F10 > again will return to normal speed. Pressing F10 has no effect when you > have the Tape Control window open, but the trick is to simply close all > UI windows and then press F10, and then the tape will be flying! :-) > I wish I had found this out earlier, I spent a lot of time waiting for > my programs to load in MAME... I'll miss that thinking time! Thank you so much for that tip. cheers, dom |
From: RobertK (<rob...@ps...> - 2019-01-01 23:10:45
|
>The successor machine "[url=https://en.wikipedia.org/wiki/Galaksija_Plus]Galaksija Plus[/url]" was downward compatible (z88dk-compiled Galaksija programs run on it without any problem), but featured - among other additions - a 256x208 monochrome graphics mode. It would be nice if this graphics mode could also be supported by z88dk, provided that it isn't too complicated to add. Today I had a look at the Github issues and noticed that Galaksija Plus hires graphics is now supported - many thanks Dom! I can confirm that the screen replication at the right edge is a Mame emulation problem. I don't have the original hardware, but I tried it on a ZX-Uno FPGA computer implementing the Galaksija Plus hardware, and there everything looks good. Here is a picture of the oncoming Galaksija Plus version of my game H-Tron, which looks entirely different from the standard Galaksija version, and it performs much better. The ZX-Uno is the little thing on the right with the yellow and white cables attached to it. [img]http://666kb.com/i/e017m3xj8yca6ofhk.jpg[/img] I'm currently working on another little cross-platform program that will make use of the full resolution, but I can't get it to work on the Galaksija because of the floating point problem mentioned above (calculating screen coordinates fails). @Dom: you can speed up MAME emulation by pressing F10, and pressing F10 again will return to normal speed. Pressing F10 has no effect when you have the Tape Control window open, but the trick is to simply close all UI windows and then press F10, and then the tape will be flying! :-) I wish I had found this out earlier, I spent a lot of time waiting for my programs to load in MAME... Happy new year! |
From: Fabrizio (<fab...@ho...> - 2018-12-30 23:55:18
|
Even a single pass could manage a backward GOTO with some tricks. But is ZSDCC single-pass? and SCCZ80? >>Is either SCCZ80 or ZSDCC one-pass or multi-pass? >>For example, can any ot these compilers efficiently optimize code with GOTO's to a backward label? >I'm pretty sure this makes no difference to zsdcc. It contains GOTO in its intermediate code and uses it for things other than the C statement. |
From: RobertK (<rob...@ps...> - 2018-12-29 19:53:32
|
I think that I have noticed a possible bug with the Galaksija target: the program crashes whenever a floating point calculation needs to be done. Here is a little test program where you can reproduce this problem: [code]// Floating point calculation test // Crashes on the Galaksija computer // Author: RobertK, 2018-12-29 // Compile with: // zcc +gal -create-app -lm -o fct floatcalctest.c // zcc +zx81 -create-app -lm -startup=2 -o fct_zx81 floatcalctest.c // zcc +zx80 -create-app -lm -o fct_zx80 floatcalctest.c // Test it in MAME like this: // mame64 galaxy -cass C:\Projects\z88dk\FloatCalcTest_galaksija.wav // Then type "OLD" to load the program and start the tape // Press F10 to speed up loading, and F10 once more to return to normal speed. #include <stdio.h> void main() { printf("\nhello world\n"); printf("\npress any key to calculate 5*0.1...\n"); fgetc_cons(); // wait for keypress printf("\n5*0.1 is %.1f\n",5*0.1); printf("\npress any key to exit...\n"); fgetc_cons(); // wait for keypress }[/code] |
From: alvin (<alv...@ho...> - 2018-12-28 05:31:29
|
>Is either SCCZ80 or ZSDCC one-pass or multi-pass? >For example, can any ot these compilers efficiently optimize code with GOTO's to a backward label? I'm pretty sure this makes no difference to zsdcc. It contains GOTO in its intermediate code and uses it for things other than the C statement. |
From: Fabrizio (<fab...@ho...> - 2018-12-25 20:04:03
|
Is either SCCZ80 or ZSDCC one-pass or multi-pass? For example, can any ot these compilers efficiently optimize code with GOTO's to a backward label? |
From: alvin (<alv...@ho...> - 2018-12-23 21:05:16
|
>Does the optimizer look at each file seperately? >Or doing global optimization? In C, each translation unit (file) is consumed independently. The only kind of optimization that could be done across files is link-time optimization and nothing like that is being done now. Within a file, optimization is done per function and per block. |
From: Fabrizio (<fab...@ho...> - 2018-12-22 22:15:10
|
Does the optimizer look at each file seperately? Or doing global optimization? If yes, which options and compiler must be used for global optimization? Fabrizio |
From: RobertK (<rob...@ps...> - 2018-10-29 23:33:16
|
[url=http://emulator.galaksija.org/MagScans/SK8511/SK8511-21.jpg]Here[/url] is a memory map of the Galaksija Plus model. The high-res video memory area starts at &C600 and ends before &E000. |
From: RobertK (<rob...@ps...> - 2018-10-29 12:40:29
|
The successor machine "[url=https://en.wikipedia.org/wiki/Galaksija_Plus]Galaksija Plus[/url]" was downward compatible (z88dk-compiled Galaksija programs run on it without any problem), but featured - among other additions - a 256x208 monochrome graphics mode. It would be nice if this graphics mode could also be supported by z88dk, provided that it isn't too complicated to add. The plus model is emulated in MAME (galaxyp) so you can check the MAME source to find out what the machine does to produce graphics. Only three software titles for the Plus model are listed [url=http://retrospec.sgn.net/users/tomcat/yu/Galaksija_list.php]here[/url]. |
From: Situs Id P. (<cc...@gm...> - 2018-10-13 09:29:21
|
mantap gan artikelnya.. sangat bermanfaat dan powerfull.. mohon difeedback ya gan <a href="http://cemeqqonline.org" >Ceme QQ Online </a> <a href="http://cemeqqonline.org" >Ceme Online </a> <a href="http://situsidpro.net" >DAFTAR ID PRO</a> <a href="http://situsidpro.net" >SITUS ID PRO</a> <a href="http://situsidpro.net" >AKUN ID PRO</a> <a href="http://cemeqqonline.org/warnetqq" >WARNETQQ</a> |
From: Dom M. <do...@su...> - 2018-10-11 10:56:47
|
On Thu, 11 Oct 2018, at 8:30 AM, siggi (si...@zx...) wrote: > > >>From my point of view (as normal user) searching in the new WIKI (my primary use case) is a big step backwards. > >It's part of a migration to github. I don't know if anything can be done about how github searching works. Unfortunately the older resources cost money to maintain which dom has been paying for years. > The old ressources cost money. > The new ressources cost privacy. > I prefer paying with money (especially for my fun/hobby/private > projects, if it 's worth). > > Siggi > > PS: Did you think about donations to keep the system up? There's a few factors beyond money that are issues at the moment. At present the website is pretty much the only thing running on the machine - I migrated all of my email off a couple of years ago. A while back I ran a trial migration of the setup to a container running on my desk. As a result of that the entire rig could be easily migrated to a (mainland) EU based VPS with minimal cost. However, this is blocked by these mailing lists. In order to pick them on the forum the machine has to be able to send and receive email and most 3rd party VPS suppliers aren't too happy about that. I could setup an account elsewhere to do that, but I'd need to check T&Cs regarding automating sending. The mailing lists had been quiet for ages (until recently), so I was hoping that they could become retired (blocked to new joiners, and shutdown a few months later). However, circumstances have conspired against that idea! Another factor is buses. Both literal and metaphorical. I'd like other people to be able to sort out any problems. If everything (as it is at the moment) is in my name then that makes things difficult, using shared resources like GitHub means that we can do this. If I could find somewhere to move the forums too I'd be happy that angle is covered too. The server that we're running on is also coming to end of life, it's slow and I think the spare motherboard I had for it no longer works. Moving back to the wiki, I've had a brief scan through the wiki history, I can see that the contributors are pretty much Alvin, Stefano and me. Thus from a privacy aspect as an end-user, I don't think it makes a massive difference that the wiki is now on GitHub since there's no requirement to sign in to view. I also can't guarantee that the connection from Germany to LD4 (where the server is) doesn't have a divert via Cheltenham. >From a contributor perspective, having the wiki on GitHub is a lot easier: I can write offline, make batch changes using command line tools, use standard MarkDown tools to generate documents. And, not have to reset my password every time I want to make a change! Yes, it has some annoyances, but on the whole from my viewpoint it's positive - and given that our documentation is still woeful in places anything to make keeping things up-to-date has to be encouraged. I hear your complaints about the search, it's a little convoluted (use top bar, get results, click on wiki in the left panel), I've not tried it, but there's a userscript that adds a search box for FireFox here: https://github.com/linyows/github-wiki-search - I'm guessing you're not really using Chrome? The move to GitHub for the source code has been positive as well, there's been something like 3000 commits since the move (i.e. from January 2017), to match that number you have to take all the commits from 2011,2012,2013,2014,2015,2016. Likewise there's more 3rd party contributors as well. I should probably briefly list some of the reasons why we moved most things from SourceForge: - Too many outages - Slow infrastructure - Uncertain future - it was being sold from company to company - Issue management was so clunky we never actually used it - Adverts everywhere Finally money, I'm not looking for any donations at the moment (I'm using the quarterly bill as incentive to do the migration), but I think in future it's something worth considering to truly bus-proof the project. Regards, dom |
From: siggi (<si...@zx...> - 2018-10-11 07:31:07
|
>>From my point of view (as normal user) searching in the new WIKI (my primary use case) is a big step backwards. >It's part of a migration to github. I don't know if anything can be done about how github searching works. Unfortunately the older resources cost money to maintain which dom has been paying for years. The old ressources cost money. The new ressources cost privacy. I prefer paying with money (especially for my fun/hobby/private projects, if it 's worth). Siggi PS: Did you think about donations to keep the system up? |
From: Fabrizio (<fab...@ho...> - 2018-10-10 20:23:25
|
Thanks! Indeed the defc solution is the clean one! Fabrizio >I personally prefer using an external asm file to define the locations of fixed items in memory. The "at" syntax in zsdcc cannot accommodate all scenarios (I think sccz80 had problems fixed some time ago) and keeping it out of the c keeps the c itself clean and portable. > >In a separate asm file, define some important memory addresses: > >[code]PUBLIC _os_clock, _os_reset_clock > >defc _os_clock = 56698 ; memory address holding an integer >defc _os_reset_clock = 62109 ; start address of function[/code] >In a C header, tell the compiler what the addresses are: > >[code]extern unsigned int os_clock; >extern void os_reset_clock(void);[/code] >Then just add the asm file to the compile line. > > >Another alternative which is related to moving BSS is to create a new memory section and place variables there. This way the C compiler lays out everything but you lose control of exact address placement and gain control of where some things are in a region of memory. This is most often used by bankswitching programs that place things in different memory banks. > >In a separate asm file declare a new section with org: > >[code]SECTION BLOCKVARS >org 0x4000[/code] >You can place asm data and code in that block in the same file. You can get the C compilers to put stuff there by changing the section assignment on the compile line. > >In the output there will be an additional binary file "*_BLOCKVARS.bin". If it's just bss data you can just ignore it. If it's bss data that your program expects to be zero then you must add code that initializes that block to zero. You can do that by inserting code into the crt in section "code_crt_init" (newlib) or by adding code to main. If it's non-zero initialized data then you must find a way for your program to initialize it separately as the c compiler won't do it for you. > > >After that you can look at defining your own memory map for full control of everything but this should be almost never necessary. |
From: alvin (<alv...@ho...> - 2018-10-10 15:39:43
|
I personally prefer using an external asm file to define the locations of fixed items in memory. The "at" syntax in zsdcc cannot accommodate all scenarios (I think sccz80 had problems fixed some time ago) and keeping it out of the c keeps the c itself clean and portable. In a separate asm file, define some important memory addresses: [code]PUBLIC _os_clock, _os_reset_clock defc _os_clock = 56698 ; memory address holding an integer defc _os_reset_clock = 62109 ; start address of function[/code] In a C header, tell the compiler what the addresses are: [code]extern unsigned int os_clock; extern void os_reset_clock(void);[/code] Then just add the asm file to the compile line. Another alternative which is related to moving BSS is to create a new memory section and place variables there. This way the C compiler lays out everything but you lose control of exact address placement and gain control of where some things are in a region of memory. This is most often used by bankswitching programs that place things in different memory banks. In a separate asm file declare a new section with org: [code]SECTION BLOCKVARS org 0x4000[/code] You can place asm data and code in that block in the same file. You can get the C compilers to put stuff there by changing the section assignment on the compile line. In the output there will be an additional binary file "*_BLOCKVARS.bin". If it's just bss data you can just ignore it. If it's bss data that your program expects to be zero then you must add code that initializes that block to zero. You can do that by inserting code into the crt in section "code_crt_init" (newlib) or by adding code to main. If it's non-zero initialized data then you must find a way for your program to initialize it separately as the c compiler won't do it for you. After that you can look at defining your own memory map for full control of everything but this should be almost never necessary. |