I've just set up a Facebook group for Atari 8-bit MADS programming if you're interested....
Jump to content
Posted Tue Sep 2, 2014 4:37 AM
Posted Tue Sep 2, 2014 3:59 PM
There's no content in there yet, so just feel free to put whatever relevant content that you like in. I need to find a balance between there and here, as here should be the main place for storing the information.
I know, in there I'll delete all the non-relevant stuff and keep it as a concise repository.
Posted Tue Sep 2, 2014 4:55 PM
I've now added some content in, i.e. links to other content.
The idea is that anyone who is into MADS can go to one place and gather lots of joined up information about MADS development.
Any waffle / non-relevant content I will delete, so that people don't have to sift through stuff to find what they want. This thread here serves a good purpose in that it allows people to communicate more, but the FB page is more for people who want to go somewhere and gather information.
Please feel free to add content and short code samples. Anything longer than say 10 or 15 lines should be linked to instead.
Posted Fri Oct 31, 2014 3:30 PM
Posted Sat Nov 1, 2014 4:11 AM
Posted Mon Jan 12, 2015 9:28 AM
Bug in relocatable file format:
WindowData .struct Status .byte ; (0=closed, 1=normal, 2=maximized, 3=minimized, +128=open window centered [will be always reset after opening]) flags .byte ; [bit0]=display 8x8 pixel application icon (in the upper left edge) ; [bit1]=window is resizeable ; [bit2]=display close button ; [bit3]=display tool bar (below the menu bar) ; [bit4]=display title bar ; [bit5]=display info bar (below the title bar) ; [bit6]=display status bar (at the bittom of the window) ; [bit7]=internal - set to 0 before opening for the first time attributes .byte ; [bit0]=adjust x size of the window content to the x size of the window ; [bit1]=adjust y size of the window content to the y size of the window ; [bit2]=Window will not be displayed in the task bar ; [bit3]=Window is not moveable ; [bit4]=Window is a super window: other windows, who point on it (see byte 51), can't get the focus position ; [bit5]=*reserved* (set to 0) ; [bit6]=Window has a horizontal scroll bar ; [bit7]=Window has a vertical scroll bar Appearance .byte ; [bit0]=Drop Shadow Border ; [bit1]=Double Border ProcessID .byte ; Process ID of the window's owner x .word ; x position, if window is not maximized y .word ; y position, if window is not maximized Width .word ; width, if window is not maximized Height .word ; height, if window is not maximized ClientX .word ClientY .word ClientWidth .word ClientHeight .word WorkXOffs .word ; x offset of the displayed window content WorkYOffs .word ; y offset of the displayed window content WorkWidth .word ; width of the total window content WorkHeight .word ; height of the total window content MinWidth .word ; minimal possible width of the window MinHeight .word ; minimal possible height of the window MaxWidth .word ; maximum possible width of the window MaxHeight .word ; maximum possible height of the window RectList .byte ; first node of window's rectangle list Title .word ; address of the title line text (terminated by 0) Info .word ; address of the info line text (terminated by 0) WinContent .word ; address of the CONTROL GROUP DATA RECORD for the window content .ends Window0 dta WindowData  (0, 0, \ ; Status, Flags WindowAttributes.Desktop, 0, 0, 0, 14, 320, 186, \ ; attrib, style, process ID, x, y, width, height 0, 0, 320, 186, \ ; client x, y, width, height 0, 0, 320, 186, 320, 186, 320, 186, 0, \ ; workxoffs, workyoffs, workwidth, workheight, minwidth, minheight, maxwidth, maxheight, appicon 0, 0, DesktopControlList)
The last struct member in "Window0" is a WORD, but the relocation table references only the LSB in the type "B" relocation table (highlighted below):
The WORD in question has offset $0488, but as you can see it's referenced only in the byte list. Needless to say, this is causes the relocating loader to fail and the program to crash. Working around this bug will require me to completely abandon STRUCTS in my project...
Edited by flashjazzcat, Mon Jan 12, 2015 9:35 AM.
Posted Thu Feb 5, 2015 4:36 PM
Its there a native way of setting the byte used in fill mode (OPT F+)?
It defaults to $FF which is fine in most cases, but I'd need $00.
Of course I can play around with align/rept to do this, but maybe there's a simpler way.
Posted Fri Feb 6, 2015 12:16 PM
.align expression, fill_value
Posted Fri Feb 6, 2015 5:52 PM
Yes, I first thought that would not work. But as long as "expression" evaluates to a value (=absolute address) greater than the current PC/"*", it should work.
Posted Sat Feb 21, 2015 5:12 AM
Hi tebe, the attached source compiles with return code 2 and no error/warning message in the build 2014-06-22. With older versions I correctly get "Undeclared label L3F96 (BANK=0)"
Posted Sun May 31, 2015 9:33 AM
Wondering why this doesn't compile correctly:
LastBank .macro .align $DFD8 LJSRCode .align $e000,$ff .ifdef Incognito .rept 4096 .byte $FF .endr .endif .endm LJSRCode .macro ; call with address of routine-1 in x,a and bank in y (note only the processor status is preserved on return) jsr Exec php ; target's RTS comes here dec BankSp ldx BankSp lda BankStack,x sta BANK ; activate bank plp rts Exec pha ; save address txa pha sty BANK ; activate bank tya inc BankSp ldx BankSp ; save bank # on stack sta BankStack,x rts ; jumps to target .endm
The ".align" pseudo-op immediately after the nested call to "LJSRCode" doesn't execute. I tested nested macro calls elsewhere and they do work, but perhaps there's something about the specific context here preventing it from working?
EDIT: Actually, getting rid of the nested call and replacing it with literal code doesn't help. And I notice that neither of the .align pseudo-ops work if there's a macro call or any code between them. Puzzling.
Aha... turns out that .align N without the optional fill parameter doesn't output any bytes at all even when the assembler's in fill mode. Changing it to ".align $DFD8,$FF" fixed it.
Edited by flashjazzcat, Sun May 31, 2015 9:52 AM.
Posted Thu Jun 4, 2015 7:54 PM
Mads compile on Ubuntu 14.04, but I have doubts with messages saying when compiling:
ascrnet@ascrnet-Inspiron-3443:~/A8/Mads$ fpc -Mdelphi -vh -O3 mads.pas Hint: Start of reading config file /etc/fpc.cfg Hint: End of reading config file /etc/fpc.cfg Free Pascal Compiler version 2.6.2-8 [2014/01/22] for x86_64 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling mads.pas mads.pas(20,2) Note: APPTYPE is not supported by the target OS mads.pas(1044,5) Note: Local variable "i" is assigned but never used mads.pas(9360,26) Hint: Local variable "par" does not seem to be initialized mads.pas(9836,27) Hint: Local variable "par" does not seem to be initialized Linking mads /usr/bin/ld.bfd: aviso: link.res contiene secciones de salida. ¿Olvidó -T? 14997 lines compiled, 0.4 sec 4 hint(s) issued 2 note(s) issued
this good or I have to add some parameter in the compilation?
Posted Thu Jun 4, 2015 11:46 PM
Posted Sat Jun 6, 2015 1:49 PM
ahhhh ok, thanks
Posted Wed Jul 15, 2015 3:06 PM
First, many thanks for the Mads Assembler! Great tool!
In my actual code I have
mva #255 TextMessageStatus StillScrolling dec hpos lda hpos and #3 sta HSCROL
This compiles to
2EF7: A9 FF LDA #$FF 2EF9: 8D 2A B4 STA TEXTMESSAGESTATUS 2EFC: 00 29 STILLSCROLLING BRK #$29 2EFE: B4 AD LDY $AD,X 2F00: 29 B4 AND #$B4 2F02: 29 03 AND #$03 2F04: 8D 04 D4 STA HSCROL
B429 HPOS B42A TEXTMESSAGESTATUS
The DEC looks faulty with its $00 instead of $CE
Debugging with source in Altirra was strange :-) Looking at the disassembly showed the problem of course.
Posted Wed Jul 15, 2015 3:13 PM
And I have another question: I want to have a list of entries and their high/low bytes
hightable dta h(label1, label2, label3, label4, label5) lowtable dta l(label1, label2, label3, label4, label5) label1 ins "data\file1.dat" label2 ins "data\file2a.dat" label3 ins "data\file3x.dat" label4 ins "data\file4.dat" label5 ins "data\file5.dat"
This is the way I do it now. But this is some work if I want to insert something between label3 and label4 (or have to use label3b)
Is there a way to use .rept or something?
Posted Thu Jul 16, 2015 12:04 PM
Are you sure your code isn't doing a rogue write of 0 to $2EFC some place?
No The error is alway 30 cm in front of the screen.
The new code works, but I wondered if that was the problem, so I used the repository and got the old source out again. And with the wonderful Altirra command
ba w 2200 L1000
I was able to check my code. And it wrote a zero to the location! Nasty bug.
(I wasn't able to get the ba command running with a hexadecimal length of F00. How is the syntax for that?)
Thank you for the help!
Posted Thu Jul 16, 2015 12:12 PM
(I wasn't able to get the ba command running with a hexadecimal length of F00. How is the syntax for that?)
Posted Thu Jul 16, 2015 12:18 PM
You mean watch for a write across a whole page?
bx "write >= $200 and write <= $2FF"
Very nice workaround!
Posted Wed Dec 14, 2016 2:37 PM
Feature request. MADS already allows a custom header in standard binaries (via ORG), but how about allowing custom headers in the native (not SDX) relocatable format? Since there isn't a main/extended segment type in the relocatable file format, I need some other way of flagging to my loader/linker that a segment should be relocated into main memory or into an extended bank. For that matter, some other information in the header (stack/proc pointers) isn't used by my loader and is just skipped. Obviously I can hack the header in a hex editor, but it would be useful to change it at compile time somehow (or even just define bits of the CONFIG or UNUSED byte).
Edited by flashjazzcat, Wed Dec 14, 2016 2:38 PM.
Posted Wed Sep 19, 2018 10:26 PM
Reviving this thread for a couple of bank-related issues.
MADS has a nice feature where labels can be associated with banks, which allows for some automagic with regard to detecting and resolving bank conflicts. However, there are some quirks with it.
First, for some reason, you cannot set a bank without setting the assembly address first:
lmb #1 bank2.s (1) ERROR: No ORG specified
Not sure why, as LMB doesn't emit code.
Second, = is a prefix operator that obtains the bank of a label or expression. It can be used to create a long-jump macro that automatically emits necessary code to switch banks. However, it conflicts with the label definition operator in funny ways:
mads 2.0.7 Label table: 01 2000 DTA mads 2.0.7 Source: bank2.s 1 org $2000 2 01,2000 lmb #1 3 = 01,2000 dta =* 4 FFFF> 01,2000-2000> 01 dta [=*]
The first DTA statement isn't actually interpreted as such, it instead defines a label called DTA with the current address (*). Adding the brackets prevents the unwanted interpretation.
Third, and the most serious: MADS in general will detect and throw errors on invalid cross-bank accesses, which is useful. Bank 0 is the global bank and allowed everywhere, while bank 1+ labels can only be referenced in that bank unless overridden with the : prefix. Attempting to access a label from the wrong bank throws an error:
mads 2.0.7 Source: bank2.s 1 org $2000 2 01,2000 lmb #1 3 FFFF> 01,2000-2003> 20 + jsr l2 4 5 02,2003 lmb #2 6 02,2003 l2: 7 02,2003 60 rts 8 jsr l2 bank2.s (3) ERROR: Undeclared label L2 (BANK=1)
This is good as it helps prevent cross-bank referencing bugs. What's not good is that procedures defined with .PROC create labels that are not checked:
mads 2.0.7 Source: bank2.s 1 org $2000 2 01,2000 lmb #1 3 FFFF> 01,2000-2003> 20 + jsr l2 4 5 02,2003 lmb #2 6 02,2003 .proc l2 7 02,2003 60 rts 8 .endp
The workaround I've found so far is to use .LOCAL, which is kind of awkward given the amount of code I have currently using .PROC.
0 members, 0 guests, 0 anonymous users