[Coco] Assembly help: Corrupted bin file ?
Fedor Steeman
petrander at gmail.com
Wed Dec 17 16:09:42 EST 2008
Thanks Robert, you are being a great help!
I must admit that I am going about this matter in a bit of a messy way. I
have read and understood most of Barden's book amongst others, but since I
never have the proper time to experiment with assembly I start forgetting
even the most basic things again. Like most people, I learn best by doing.
One of my problems has been a lack of a good assembler that I can move back
and forth from whenever I find the time. The Portal-9 and RainbowIDE
products are perfect for this, but for some reason I have never properly got
them to work. The code fragment you are looking at actually is taken out of
a CoCo program that I ran through a disassembler in order to analyse.
What I am doing now is just running the CASM assembler on a command prompt
while editing the source file in a text editor. Since I have VCC installed I
can simply double-click the bin-file and it is automatically mounted in the
emulator. This works fine with the bubblesort program provided in
RainbowIDE. So I am not using a virtual diskette as a go-between but have
the machine code directly written in the emulated memory and executed.
I now made the necessary changes to the source code I showed you and it is
mounted without problems! The program is executed in VCC and shows a pmode 4
screen with vertical stripes as expected. However, the stripes aren't as
narrow as I expect them to be. Using $AAAA which translates to binary 1010
1010 1010 1010, I would expect pixel-wide alternating black and white
vertical lines. What I am getting, though, are much broader vertical black
bars interrupted by paired vertical stripes. Any explanation for that?
Cheers,
Fedor
2008/12/17 Robert Gault <robert.gault at worldnet.att.net>
> Fedor,
>
> There could be several things wrong here depending on how you tried to use
> this with VCC. There is also a problem with the source regards CCASM or any
> of the assemblers that are used with a Coco.
>
> It would help to know how you tried to use this with VCC.
>
> Comments are inserted below.
>
> "Fedor Steeman" <petrander at gmail.com> a écrit dans le message de news:
>> dcc956220812162330t4b8be888je63b60fd6321d19f at mail.gmail.com...
>>
>>> Hello everyone,
>>>
>>> I am still trying to learn assembly language but keep on running into
>>> problems.
>>>
>>> I have been trying to have the following source code assembled:
>>>
>>> VIDRAM EQU $0400 *Start of Video Display location
>>> V0CLR EQU $FFC0 *Clear bit for Sam Chip (Graphics mode)
>>> V1SET EQU $FFC3 *Set V1 bit in Sam Chip (Graphics mode)
>>> V2SET EQU $FFC5 *set V2 bit in Sam Chip (Graphics mode)
>>> VOFSET EQU $FFC6 *Display Offset Binary, This is the CLR Bit
>>> (Video page offset)
>>> VDGSET EQU $FF22 *PIA1 data port B: VDG Control output
>>> POLCAT EQU $A000 *Color Basic rom poll keyboard routine
>>>
>>> ORG $21FD
>>> LDX #VIDRAM *331D: 8E 04 00
>>>
>>
> This next can't be what you wanted. Almost certainly you intended to store
> the value $AAAA into memory. That means the next line should be changed to
> LDD #$AAAA
>
> LDD $AAAA *3320: CC AA AA
>>> Z3323 STD ,X++ *3323: ED 81
>>> CMPX #$1C00 *3325: 8C 1C 00
>>> BCS Z3323 *3328: 25 F9
>>>
>>
> There is no reason for the next line. It is not required for a timing issue
> and certainly was not used to block out previous code. :)
>
> NOP *332A: 12
>>> PMODE4 STA V0CLR *2787: B7 FF C0
>>> STA V1SET *278A: B7 FF C3
>>> STA V2SET *278D: B7 FF C5
>>> LDA #$F8 *2790: 86 F8
>>> STA VDGSET *2792: B7 FF 22
>>> STA VOFSET *2795: B7 FF C6
>>>
>>
> The next two lines have two problems, one already mentioned by another
> reader is the keyboard is only checked once so any key press is likely to be
> missed. The other is the use of JSR then RTS. Since the JSR already has an
> RTS at its end, that results in RTS RTS which is a waste of space and time.
> There are several ways of changing the code depending on whether you need
> the value of the key pressed or are just waiting for any key to be pressed.
> I prefer in the latter case to just use the Disk Basic code and JSR $ADFB.
> In your code example, it would just be JMP $ADFB.
> However, assuming you might want the value of the pressed key and using the
> example of POLCAT, the lines should be
>
> L1 JSR [POLCAT]
> BEQ L1
> do something with the key value
> RTS
>
> JSR [POLCAT] *332E: AD 9F A0 00
>>> RTS *3332:
>>>
>>
> This needs and END statement and if you intended to LOADM the code it also
> needs a reference to the execution address. The following changes are
> needed.
>
> >> ORG $21FD
> >> Start LDX #VIDRAM *331D: 8E 04 00
> ....
> >> JSR [POLCAT] *332E: AD 9F A0 00
> >> RTS *3332:
> END Start
>
>>
>>> Using Roger Taylor's CCASM (as included in RainbowIDE) I get the
>>> following
>>> binary file:
>>>
>>> The origin of the code is shown below (the 2421) but the length of the
> sequence is zero (the first two 00 00). CCASM did not know how long your
> program should be. Also you may not have selected the correct Object Output
> in RainbowIDE.
>
> 00 00 24 21 FD 8E 04 00 FC AA AA ED 81 8C 1C 00
>>> 25 F9 12 B7 FF C0 B7 FF C3 B7 FF C5 86 F8 B7 FF
>>> 22 B7 FF C6 AD 9F A0 00 39
>>>
>>
> As mentioned by another reader, there is no footer to this code to be used
> by LOADM.
>
>
>>> When I try to run this binary file using the VCC emulator I get an error
>>> message stating that the binary file is corrupt.
>>>
>>> Can anyone help me try to understand whether there is anything wrong with
>>> my
>>> source code, the assembler (i.e. the resulting binary file) or the
>>> emulator?
>>>
>>> Thanks in advance!
>>>
>>> Cheers,
>>> Fedor
>>>
>>
> You probably should indicate exactly how you asked RainbowIDE to compile
> your code because there might be something wrong at that end of the process.
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
More information about the Coco
mailing list