[Coco] Assembly help: Corrupted bin file ?

[Fedor Steeman]

Hi,

I discovered it was just a typo! All is now working as expected and I look
forward to experimenting some more! :-)

Thanks for all the help, guys!

Cheers,
Fedor

2008/12/17 Fedor Steeman <petrander at gmail.com>

> 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
>>
>
>